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 <http://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
