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
