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?
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!
Fast because its unreliable transport
TCP makes assurances about delivery and order
And putting any code in to make assurances about packet delivery & ordering probably means you should use TCP
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.
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?”
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.
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)
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
Fast, lean communications where reliability isn’t as important as speed. One-to-many communication.
That’s pretty much why I’ve been playing with UDP
- Speed is key
- One To Many comms
[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).
I’d go with Greg’s suggestion. I don’t think the clients would handle images with missing bits very well.
[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.