|
From: Black M. <mdb...@ya...> - 2016-06-10 14:33:07
|
Yeah...I agree it's a step towards TCP but the stateless nature is still handy for our use. And UDP over local network is quite reliable (via loopback and typically good over LAN too).I wasn't thinking of ack/nak for all packets...just the request from the client that Laurie is talking about.
I did work on a project many years ago where they started with UDP and eventually reinvented TCP with hundreds of lines of code that was unstable which I replaced with something like a 10-line program for TCP that was rock solid. It was a job for the White House Communication Agency. RRRMike W9MDB
From: Bill Somerville <g4...@cl...>
To: wsj...@li...
Sent: Friday, June 10, 2016 9:25 AM
Subject: Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify decodes to will accept UDP reply command.
On 10/06/2016 13:24, Black Michael wrote:
One possible solution is a simple ack/nak packet.
Hi Mike, that doesn't really sit well with the fire and forget nature of UDP messages. Once you start adding conversational protocols you might as well use TCP/IP but that requires asynchronous processing or threads and a whole lot of state for each "client". The current UDP message infrastructure in WSJT-X is stateless at the connection level and synchronous, very simple and no waiting for network replies. 73
Bill
G4WJS.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
|