Wow -- that generated a lot of discussion. In no particular order: * Yes, the test server should be working on UDP and TCP. * Yes, you can send the UDP packets when they are full. The 5 minute constraint is a hold over from the days when there were only a couple of spots in that time and I wanted a balance between timeliness and being hammered by packets. In some sense, I'd prefer more evenly spaced packets rather than a block every 5 minutes. * I don't think that the cost of a single idle TCP connection will be noticeable for a modern PC. Back when I started this, systems were a lot slower (and with a lot less memory) than they have today. The server bottleneck at the moment is the fact that the packet decoder is single threaded and written in perl. The database can also cause problems.... * I suspect that the cost on my end for handling lots of connections is probably pretty similar to handling UDP -- with the exception that there is some setup and teardown cost. * My server is not currently short of CPU.... Over the last 24 hours, it has been under 50% used. * There is additional complexity in being a TCP sender as Bill notes -- what do you do when you can't establish the connection, what to do when the connection goes away unexpectedly etc. What if you can't send a packet (as the connection has got stuck). My inclination would be to keep it simple and do something like the following:
. At startup make the TCP connection (non-blocking) . When you want to send a packet, send it (non-blocking). If it fails (for whatever reason), then close and reconnect (non-blocking) [Could also send the packet as a UDP message] With a bit of luck, if you only want to send a packet every minute or so, then the TCP connection will have established itself during that interval. More complex schemes would have to involve packet queues and the like..... Philip On Sun, Jun 7, 2020 at 8:33 AM Black Michael via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Since you're already batching the reports in 5 minute intervals I wouldn't > keep the connection open. > Just make it, report, and close it. And if it gets an error just drop 'em > and maybe stuff a message in the decode window (rather than a dialog box) > that says "PSK Reporter error" maybe with the error message. So at least > those individuals that seem to care will know their spots are dropped. > > This reminded me of an old argument I had with a banking client when they > tried to claim TCP was a guaranteed protocol. I actually had to contact > Bob Kahn to convince them otherwise as they couldn't' seem to understand > the OSI 7-layer model....all of which made me very leery of banking.... > > Mike W9MDB > > > > On Sunday, June 7, 2020, 04:11:10 AM CDT, Bill Somerville < > g4...@classdesign.com> wrote: > > > On 07/06/2020 02:23, 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 > > Hi Philiip, > > sorry to hear you are being given grief for your good design decision to > use UDP for the PSKReporter incoming data feed. The extra burden at both > client end and server end is considerable to housekeep a connected > transport protocol. Nevertheless if users feel that every single spot is > critical and none must be missed during normal operation; then we of course > will be happy to make the required changes to give WSJT-X users the option > to use a connected protocol rather than unconnected "fire and forget" UDP > protocol. Is the test server also TCP/IP capable? > > On your comment about when to send spots, are you saying that sending once > a full block is gathered is recommended for UDP rather than waiting 5 > minutes, or are you recommending that should be done just for TCP/IP? > > For those that may claim TCP/IP is and easy switch with many appropriate > attributes, note that to TCP/IP the server end must keep a data structure > alive for every separate connection, and there will potentially be > thousands of them concurrently, whereas with UDP all users can be handled > by a single service just recording the source details in the database as > UDP datagrams are received, then moving on to the next. IMHO maintenance of > such semi-permanent connections per data source is a large price to pay for > more reliable delivery of data that has greatest value in bulk, and where > ultimate reliability adds little apart from those at the end of unreliable > network connections. Those same users of unreliable network connections > will require the implementation of the most complex clients since any > guarantee of delivery necessarily implies complex handling of timed out > connection failures. I.e. what should WSJT-X do with spot information it > cannot deliver because a TCP/IP connection has broken down? How long should > it store spot data in the hope of a resumed TCP/IP connection? How long > before such spot data becomes stale, and not worth delivering? None of > these decisions are necessary with a UDP implementation where delivery > guarantees are only dependent on a working uncongested path between clients > and the server. > > 73 > Bill > G4WJS. > _______________________________________________ > 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
