Having got frustrated with twenty second stalls, and convinced there is some issue with 'LwIP', I decided to take a look at UDP as that should be much simpler processing for the protocol than TCP and it does indeed seem to be more reliable. I am sure that's helped by both client and server only ever opening one socket and never closing it.
It's not perfect because there are at least four issues -
It's no good if you actually need to interface to something which has to be TCP, such as HTTP servers etc, but it should be okay to use for simply passing chunks of data around.
The payload size is limited but you can implement your own splitting and re-assembly of data. If the payload is small enough it shouldn't be an issue.
It's not guaranteed that what is sent via UDP will get delivered to the other side and, while most times it is, my experienced is that it sometimes doesn't. But that might not be a problem if using a send-reply regime where a timeout on a reply can simply provoke a resend, using a reference ID can let you check the reply is for the last packet sent.
Being UDP it's entirely possible that something other than the server could reply to a client waiting for a response. I don't think that's very likely on our own networks and magic markers, sequence numbers, and checksums, could be deployed. We are somewhat re-inventing TCP but but I don't think we would need to go the full hog on that.
I did have one 'unreachable host' or something like that when I started the client running one time and restarting the server wouldn't cure that. Restarting the client did.
I need to investigate that and do some soak-testing, but once that's complete I will post my code.
5,000 requests from client to server, 7 lost packets which needed retransmitting, zero errors. So it's looking good so far.
It's not perfect because there are at least four issues -
It's no good if you actually need to interface to something which has to be TCP, such as HTTP servers etc, but it should be okay to use for simply passing chunks of data around.
The payload size is limited but you can implement your own splitting and re-assembly of data. If the payload is small enough it shouldn't be an issue.
It's not guaranteed that what is sent via UDP will get delivered to the other side and, while most times it is, my experienced is that it sometimes doesn't. But that might not be a problem if using a send-reply regime where a timeout on a reply can simply provoke a resend, using a reference ID can let you check the reply is for the last packet sent.
Being UDP it's entirely possible that something other than the server could reply to a client waiting for a response. I don't think that's very likely on our own networks and magic markers, sequence numbers, and checksums, could be deployed. We are somewhat re-inventing TCP but but I don't think we would need to go the full hog on that.
I did have one 'unreachable host' or something like that when I started the client running one time and restarting the server wouldn't cure that. Restarting the client did.
I need to investigate that and do some soak-testing, but once that's complete I will post my code.
5,000 requests from client to server, 7 lost packets which needed retransmitting, zero errors. So it's looking good so far.
Statistics: Posted by hippy — Sun Mar 10, 2024 7:59 pm
