I did not see Steve's reply before I sent mine. While I disagree with the conclusion that "Peter’s overview is 100% correct.", I don't think we have to reach agreement on that point. If you are designing a client/server application, and want to make a call as if you should implement communication via TCP or UDP, there are many, many, many reference materials on the subject that you can refer to and inform yourself with.
The larger point, and I think Steve and I agree on this, is that "both" might be the best choice here. If UDP is not working for you to register your information to PSKreporter, switch to TCP. I also agree with Steve that this reporting mechanism is best handed by a third party library, and that a native implantation by WSJT-X is probably not the right way to go. Thanks. Robert. AD6I. On Sat, Jun 6, 2020, at 11:09 PM, Stephen VK3SIR wrote: > Hi Folks, > > Interesting discussion. Peter’s overview is 100% correct. Philip > (PSKReporter’s maintainer) states that his resource should only offer a > “guide” and I must also highlight that. > > TCP should be perhaps only used in the exception and only if uploads to > PSKreporter are observed to not register . > > As the circumstance that Phillip has made accommodation for is more for > anomalies – the exception - possibly this functionality is best and most > easily implemented within 3’rd party addons such as JTAlert (i.e. disable > sending from WSJT-X and send from the 3rd party app via TCP)? > > Laurie VK3AMA I believe follows this list and his comments on this will also > be of interest; flag this in the JTAlert forums as I am sure that this is a > facility that may be easily (and perhaps best) implemented there. > > 73 > > Steve I > VK3VM / VK3SIR > > *From:* Peter Sumner <vk8...@gmail.com> > *Sent:* Sunday, 7 June 2020 3:43 PM > *To:* WSJT software development <wsjt-devel@lists.sourceforge.net> > *Subject:* Re: [wsjt-devel] WSJT-X and PSKReporter > > 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
