- "Hi, I'd like to hear a TCP joke." -
"Hello, would you like to hear a TCP joke?" - "Yes, I'd like to hear a TCP joke." - "OK, I'll tell you a TCP joke." - "Ok, I will hear a TCP joke." - "Are you ready to hear a TCP joke?" - "Yes, I am ready to hear a TCP joke." - "Ok, I am about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline." - "Ok, I am ready to get your TCP joke that will last 10 seconds, has two characters, does not have an explicit setting, and ends with a punchline." - "I'm sorry, your connection has timed out. Hello, would you like to hear a TCP joke?" -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/CM/CC/E/IT/TW d-@ s+:+ !a C++$@ UBLVSCX*++++(on)$>$ P++>$ L+++$ E+@ W++>$ N+++ o+@ K+++ w@ O+@ M-@ V@>$ PS+@ PE@ Y+ PGP++ t+ 5+ X++ R@* tv++ b+>$ DI++ D+ G++ e h r+++ y+++ ------END GEEK CODE BLOCK------ On Sun, Jun 7, 2020 at 10:53 AM Philip Gladstone < pjsg-w...@nospam.gladstonefamily.net> wrote: > 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 >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
