UDPSocket - Error 40...

General
1

I’ve been playing with UDPSocket for a small project I’m working on.

Everything is working absolutely fine if I’m sending a straight string as the datagram data. It’s being sent and received fine. I’m adjusting this to send now a picture which is obviously a lot more data and I’m running into an error 40 when I try to write the data. Error 40 being message too long.

  • I initially tried converting the image to a memory block and sending the string representation of that - no joy
  • I then tried converting the image to a string using a MBS function PictureToJPEGStringMBS - no joy
  • I tried increasing the sockets buffer size with another MBS option OptionSendBufferSizeMBS - no joy

Any ideas what else I can try? Indeed, Should I forget trying to send images via UDPSocket and stick to TCP?

2

Why UDP?

3

I’m intending to ramp up the frequency this data is sent out. Quite a few times a second. My understanding is that UDP is nice and fast.

No objections whatsoever to changing protocol if that’s for the best!

4

Fast because its unreliable transport
TCP makes assurances about delivery and order
UDP doesn’t
And putting any code in to make assurances about packet delivery & ordering probably means you should use TCP

5

As I recall, you’re going to find that the maximum transmission size is about 8K with UDP. You may be better off using a ServerSocket for serving the images and then UDP to notify the client’s that a new image is available.

6

A lot of this is my playing/experimenting, done TCP work but very little UDP.

TCP it is - no problems. Does raise the obvious question “What is UDP good for then?”

7

I used it in a project to create an external notification system so I could send a message to other terminals that a particular customer record had been changed and if the other terminals had that data displayed, they should re query the database.

8

But given Norman’s response about being unreliable & lack of assurances why would you choose UDP? I get that you used in a project but why choose that protocol rather than TCP if it gives you robustness? (robust may be a poor word)

9

lots of games use it because it is fast and missing a tiny bit of info is usually not fatal or relevant

group notifications of some kind

10

Fast, lean communications where reliability isn’t as important as speed. One-to-many communication.

11

That’s pretty much why I’ve been playing with UDP

  • Speed is key
  • One To Many comms
12

[quote=109805:@Patrick Delaney]That’s pretty much why I’ve been playing with UDP

  • Speed is key
  • One To Many comms[/quote]

and you dont care if you drop a random packet here or there. UDP has no way of determining that you have lost a packet and telling the other side to retransmit it. You have to gracefully accept/handle the lost packet(s).

13

I’d go with Greg’s suggestion. I don’t think the clients would handle images with missing bits very well.

14

[quote=109787:@Patrick Delaney]I’m intending to ramp up the frequency this data is sent out. Quite a few times a second. My understanding is that UDP is nice and fast.

No objections whatsoever to changing protocol if that’s for the best![/quote]

Pat unless you are looking to send Real Time data such as Voice over IP or Video over IP I would always use TCP. As the others have pointed out the reasons. TCP is pretty fast also as I am using it for many of my protocols I have invented.