Since the TCP/IP protocol standard takes care of error correction/checksums within the packet communication, is it ‘safe’ to assume I don’t need to implement any of my own error correction handling while using the easyTcpSocket/tcpSocket controls?
I’d say yes it’s safe. Look at protocols like HTTP and FTP: no error correction at all!
In general, yes. There may be special use-cases where guaranteed delivery of your data does not necessarily mean you should not error-check that data on the receiving side. For instance, if you are writing medical software that may potentially be involved with patient treatment, I would not trust my data to the transport layer only.
Also note that TCP sockets are quite a bit slower than UDP. If you are at all concerned with speed and latency, go ahead and design your own error correction / handling on top of UDP sockets.
Appreciate the feedback. I do have one more question about the easyTcpSocket (new to it). Perhaps you guys could assist with the answer. Suppose I have a file/string that is 150KB long. I load the file into a memoryblock and transmit the memoryblock.string all at one time. Since easyTcpSocket uses the ‘ReceivedMessage’ instead of ‘DataAvailable’, will the entire file/string become available at once, once the event fires? No need to sit there and parse through data in blocks/segments as they come in like using the tcpSocket?
I believe that is the case. Have you tried it yet? I’ve never used EasyTCPSocket yet, as I’m usually talking to stuff not written in Xojo.
I’m interested to know what you find.
Thanks!
[quote=44317:@Kimball Larsen]
Also note that TCP sockets are quite a bit slower than UDP. If you are at all concerned with speed and latency, go ahead and design your own error correction / handling on top of UDP sockets.[/quote]
UDP is faster BECAUSE it does not guarantee anything - not even delivery.
Layering error correction & packet resends etc will roughly give you most of what TCP gets you for free
I’ve found (especially when talking to embedded wireless devices) that the TCP handshake for both setup and teardown is massively slow. (i.e., sometimes it can take several seconds to establish a connection). With some of our devices switching to UDP and employing rudimentary error checking / retry with sane timeouts is always faster than TCP.
But in general, Norman is right: Putting some error correction on top of UDP is going to increase overhead. If you don’t need everything TCP provides, though, UDP with custom error checking where it counts can be MUCH faster.
The data I will be transferring is important and can not contain errors; otherwise, I would use a different and faster protocol. Speed isn’t much of an issue, as I’ll only have the system connect once every two hours, and only transfer between 2K-10K on average with each connect.
Use TCP
REALLY ? What kind of devices ?
Sure hope its not SCADA or anything critical like that where errors & dropouts are NOT acceptable