Hi Peter: While its true that the TCP protocol puts additional computing requirements on both the sender (the local PC) and the recipient to guarantee the reliable, ordered, and error-checked delivery of data, these additional requirements are nearly insignificant in modern fast networks and network devices.
But the transmission of packets and their acknowledgement in TCP does not quite work as you describe. There is a negotiated window size of how much data can be sent by the client before requiring acknowledgment of any data. This window can be quite large, 1GB on networks with sufficient capacity. It's not quite as simple as "send packet, wait for acknowledgement, send next packet" as implied by your description. Both UDP and TCP have their place, but the trend is away from UDP and towards TCP. There is also an additional trend away from TCP and towards recent new protocols designed to address the shortcomings of TCP, such as QUIC or SCTP. I can think of many examples where UDP is important (media streaming), where TCP has supplemented UDP (NFS), and support for both is appropriate, as it would appear here. My larger point, the one which prompted me to write, is that its nowhere as simple as "use UDP, its more popular". Thanks. Robert. AD6I. On Sat, Jun 6, 2020, at 10:42 PM, Peter Sumner wrote: > Hi Adrian, messages via TCP put a requirement on the local PC to handle > errors which all add complexity and resources to do it. The messages have to > be sent, an answer waited for and if no answer, sent again until a time out > is received, then handle this time out... UDP on the other hand is a send it > and move on to the next thing process which requires very little overhead and > no error handling by the sender. This is why UDP messaging is so popular as > you do not have to worry about the outcome of a send and generally works on > most networks. > > Regards, > Peter, vk5pj > > On Sun, Jun 7, 2020 at 3:03 PM Adrian <vk4...@gmail.com> wrote: >> This sounds like a great idea. I am surprised it is not already done via tcp. >> >> On 7/6/20 11:23 am, Philip Gladstone wrote: >>> There are a (small) number of WSJT-X users who have difficulty reporting >>> their spots to pskreporter. Some of these are in "difficult" areas of >>> network connectivity (e.g. Marine Mobile) and I suspect that the UDP >>> transport is losing most of their packets. The general loss rate seems to >>> be around 1%-2% which is somewhat higher than I would expect, but it is not >>> unbelievable either. >>> >>> It is also difficult to diagnose these sort of problems as the packets >>> appear to leave the PC running WSJT-X and not arrive at my server! >>> >>> PSKReporter was never supposed to be 100% reliable, but there seem to be a >>> lot of people who think otherwise.... >>> >>> In an effort to improve the situation, I have now stood up a TCP listener >>> that might help. The protocol is identical -- the only difference is that >>> you send the same messages as before over a TCP connection to >>> report.pskreporter.info port 4739 rather than over a UDP connection. There >>> is no extra framing required as the messages already contain a length code. >>> >>> The listening server should be able to support enough connections. It will >>> close a connection if an invalid message is received. >>> >>> Is this change something that could be implemented? Also, currently, you >>> send a bunch of packets at the same time (on the five minute expiry). You >>> could send them as soon as they get "full" rather than waiting. >>> >>> Thanks >>> >>> Philip >>> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
