Hi Saku,
I will try and help with terminology.
The most usual client/server topology is one server that serves many
clients. For example a web server serves http(s) page requests to many
clients. The client sends the query to a well-known server address and
service port, the server replies to each client on the client's IP
address ephemeral port number that were extracted from the request
sender address and port fields. The WSJT-X UDP Message protocol is no
different, except that the underlying transport is UDP rather than
TCP/IP. Perhaps your confusion comes from you having not bothered to
support multiple clients, that seems a strange decision to me, a server
that only supports a single client is a very limited service!
With `git checkout`, perhaps you are thinking check-out like from a
hotel. It is more like check-out a book from a library. You are
borrowing a version of your source code from the index (the local
repository) to work on it, you will return it later. A different meaning
for check-out.
73
Bill
G4WJS.
On 30/07/2020 15:22, Saku wrote:
The server/client implementation has been always impossible to
understand. I have silently accepted way "reverse what you are
thinking - that is ok".
Just cannot help that in my way of seeing things that is opposite.
Similar problem with GitHub "checkout" that in my mind is to LEAVE
branch, but it is to ENTER branch (again thing that just must accept
to be inverse).
Perhaps that is because I'm not native English speaking.
Sometimes I get error splash from wsjt-x:
"Network error Error: Unable to send a datagram UDP server
239.255.0.0:2237" (cancel / retry)
Retry gives splash again. After that wsjt-x freezes: cancel/retry does
not react any more and monitoring on main screen stops. When trying
to close wsjt-x from left top "X" causes Fedora's own prompt "Wsjt-x
is not answering" and offers to kill the program.
Last time it happened when wsjt-x was running and cqrlog was
monitoring ok and then I started udp_daemon -p2237 -g239.255.0.0
How ever cqrlog and newly started udp_daemon continued to monitor
decoded frames from wsjt-x when I left splash cancel/retry untouched.
For "colorback" and qso initiate I use own socket that is bind to same
239.255.0.0:2237 multicast address (way that was copied from sample
code). I tried to send also to receiving socket and it also seems to
work. So I'm not sure what is right way.
Anyway in both cases cqrlog can not handle multiple wsjt-x clients and
I do not know what would happen if there are more than one wsjt-x
client in same multicast group.
Bill Somerville kirjoitti 30.7.2020 klo 15.59:
Hi Saku,
RR, it is not difficult to implement. The main problem has been code
written with ancient programming languages and scripting tools (VB6
and AutoIt to name two) that have no support for joining multicast
groups. In both cases it should have been possible to call the
underlying Win32 API functions but that has not happened :(
Also note that traffic back to the clients (WSJT-X) is still unicast
and addressed to sender address of individual WSJT-X clients, there
is no multicast in that direction.
73
Bill
G4WJS.
--
Saku
OH1KH
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
