We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm using tcpnet and can make a connection to a server beautifully.
Sometimes a tcp message i send does not get through to the server. I think I need to resend it but don't know how long to wait before trying.
Are there any rules for this?
If you are using TCP, then the network stack has logic to resend information.
If you use UDP, then it is your application that needs to implement a system with acknowlede and resends/timeouts.
If you're using TCP then it is the responsibility of the protocol stack to ensure the data gets through reliably. That includes the necessary mechanisms to look after lost packets and duplicated packets.
So, assuming that the connection remains established, your application should assume that the data you feed into the stream at one end will get through at the other end in the same order in which you sent it.
You should not retransmit a block that does not get through within your expected time frame. If you do, then what you should ultimately get through at the other end will be both the original block and then the repeated one.
This holds true for whatever medium that the TCP session is communicated across - Be it cable, wireless, radio, whatever.
You may choose other reasons for sending a block again or doing other things to provide extra integrity checks, but 'loss of data blocks' should not be one of those reasons. TCP is considered to be a reliable connection.
If people say otherwise, they are wrong. Unfortunately it does appear to be a frequent assumption (especially when communicating across radio) that because the underlying link is bad, retransmission of a block should occur. Strange what people do when they don't understand TCP/IP correctly or prefer to blame an underlying stack rather than correct their application.
It is my _guess_ that people have noticed that a web browser gets a page faster if you press reload, than if you wait for the TCP/IP stack to resend after a transfer error.
The TCP/IP stack can wait quite a while before it makes the resend of lost data. So for a web browser, it can save time to press reload multiple times and have the browser to a new connect instantly when the link comes up again. But that is a very big difference from handling packet loss on an ongoing TCP transfer.