Re: [wsjt-devel] WSJTx Setting Window

[August Treubig]

32 bit or 64 bit version?.?   64 still has qt issues.   


Aug
AG5AT 

Sent from my iPad

> On Oct 15, 2019, at 10:37 PM, Donn Taylor  wrote:
> 
> Just updated to the latest WSJTx that supports FT4.   When I first open the 
> program the setting window is available and I am able to make changes without 
> any problems.  If I start using the program, when I try to select the setting 
> window with either the F2 or the tab, the settings window is all blank.   If 
> I close the program and restart the program the settings window displays, but 
> goes blank again.   Depending upon where the cursor is in the window, 
> different dialog boxes will have some information.   Never had the issue, 
> until I updated 
> 
> Donn  K0QC
> 
> Patriotism is supporting your country all the time, and your government when 
> it deserves it.  Mark Twain
>> 
> ___
> 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

Re: [wsjt-devel] UDP Client / Server frame of reference

[Michael Pittaro]

On Tue, Oct 15, 2019 at 12:07 PM Bill Somerville 
wrote:

>
> Hi Mike,
>
> clients must discover the server they talk to somehow. For example web
> servers are discovered via hypertext links or by typing a web server
> address and port number into the client user interface of the client web
> browser. It should be no surprise that a client has to be told what server
> it is expected to communicate with. the server already knows what it is, it
> is the client that needs to be told about servers.
>
> 73
> Bill
> G4WJS.
>
>
Bill,

I 100% agree.  But you have an advantage - you designed and wrote the
code.  You _know_ wsjt-x is a client.  There's nothing in the user guide or
UI to tell me wsjt-x is a client.  Or even give me a hint.  I interpreted
the server and port fields as the address and port for the (non-existent)
wsjt-x server to listen on.   I had a 50/50 chance to get it right, and I
took i :-).  I got it wrong, and learned a bunch is the process :-)  I'm
attaching my proposed UI usability enhancement...

[image: ui_enhancement.png]

On a more serious note, now that I have switched things around, I'm able to
talk to wsjt-x over the UDP connection.  Thanks for all the assistance - it
has been helpful and educational.

mike, kj6vcp
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTx Setting Window

[Black Michael via wsjt-devel]

A known bug -- just resize the window and it will show again.
de Mike W9MDB

 

On Tuesday, October 15, 2019, 10:43:19 PM CDT, Donn Taylor  
wrote:  
 
  Just updated to the latest WSJTx that supports FT4.   When I first open the 
program the setting window is available and I am able to make changes without 
any problems.  If I start using the program, when I try to select the setting 
window with either the F2 or the tab, the settings window is all blank.   If I 
close the program and restart the program the settings window displays, but 
goes blank again.   Depending upon where the cursor is in the window, different 
dialog boxes will have some information.   Never had the issue, until I updated 

Donn  K0QC

Patriotism is supporting your country all the time, and your government when it 
deserves it.  Mark Twain















___
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] WSJTx Setting Window

[Donn Taylor]

Just updated to the latest WSJTx that supports FT4.   When I first open the 
program the setting window is available and I am able to make changes without 
any problems.  If I start using the program, when I try to select the setting 
window with either the F2 or the tab, the settings window is all blank.   If I 
close the program and restart the program the settings window displays, but 
goes blank again.   Depending upon where the cursor is in the window, different 
dialog boxes will have some information.   Never had the issue, until I updated

Donn  K0QC

Patriotism is supporting your country all the time, and your government when it 
deserves it.  Mark Twain

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprnet abandoned

[Dana Myers]

On 10/14/2019 7:39 PM, Onno Benschop wrote:

Eric, the frustration in your email is visceral and leads me to one question:

When did you last pay for an SLA in relation to wsprnet?


No good deed.

Dana  K6JQ



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Bill Somerville]

On 15/10/2019 15:02, Michael Pittaro wrote:
On Tue, Oct 15, 2019 at 9:34 AM Black Michael via wsjt-devel 
> wrote:

>
> NetworkMessage.hpp -- several places.  Though after reading some 
more descriptions it does seem to free flow back and forth as to who 
is client and who is server.  The message aggregator is referred to as 
a servernot sure whyin my book a server is the one piece that 
can run by itselfclients aren't required. Clients are useless 
without the server.   I think the code comments were written to be 
very generic as the client/server relationship is very much message 
specific to In/Out.   UDP protocol doesn't really have a 
cliient/server architecture...just a protocol that rides on it.  You 
could just as well replace client/server with "program and another 
program".

>

This is what tripped me up as well.   I didn't find the code or 
description to be wrong. It's fairly clear about client and server 
roles.  It just never points out that wsjt-x is a 'client', and it's 
easy to miss that, since the UI says 'UDP Server.'


mike, kj6vcp


Hi Mike,

clients must discover the server they talk to somehow. For example web 
servers are discovered via hypertext links or by typing a web server 
address and port number into the client user interface of the client web 
browser. It should be no surprise that a client has to be told what 
server it is expected to communicate with. the server already knows what 
it is, it is the client that needs to be told about servers.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Bill Somerville]

Mike,

a network server in an IP network is an application that binds a service 
port on one or more network interfaces and listens for traffic from 
clients. Network clients discover the server by some prearranged 
mechanism and send messages to the server with the option to receive 
replies back from the server on an ephemeral service port. This is true 
for both UDP and TCP although the TCP connection is connection and 
stream orientated and persists throughout a communications session 
whereas UDP communications are connectionless consisting of datagram 
blocks which stand alone. Either way bi-directional communication is 
possible and normal. The distinguishing feature of a server is that a 
single server  may have many clients.


Given the above WSJT-X is a client and an application wishing to 
interoperate with WSJT-X is a server. I don't see how that can be seen 
any other way. Note also that a server is only a server because it 
serves clients. Your statement about a "server" without clients makes no 
sense, a server can have no clients at some point in time but it is not 
a server if it cannot accept client messages and do something with them.


The terms client and server are more about how communication is 
established and the cardinality of relationships, not as you state a 
protocol that is implemented using UDP or TCP.


I still do not see any references to servers in the WSJT-X sources that 
are incorrect, likewise references to clients. The text you quote from 
NetworkMessage.hpp is describing the protocol and as such it refers to 
both clients and servers, it must do that to make any sense.


73
Bill
G4WJS.

On 15/10/2019 14:32, Black Michael via wsjt-devel wrote:
NetworkMessage.hpp -- several places.  Though after reading some more 
descriptions it does seem to free flow back and forth as to who is 
client and who is server.  The message aggregator is referred to as a 
servernot sure whyin my book a server is the one piece that 
can run by itselfclients aren't required. Clients are useless 
without the server.   I think the code comments were written to be 
very generic as the client/server relationship is very much message 
specific to In/Out.   UDP protocol doesn't really have a 
cliient/server architecture...just a protocol that rides on it.  You 
could just as well replace client/server with "program and another 
program".


 * it  is essential  that clients  and
 * servers  of  this protocol  can  agree  on  a common  scheme.   The
 * NetworkMessage  utility classes  below exchange the schema  number
 * actually used.  The handling of  the schema is backwards compatible
 * to  an  extent,  so  long   as  clients  and servers  are  written
 * correctly. For  example a server  written to any particular schema
 * version can communicate with a client written to a later schema.


 *    message is intended to be used by servers to detect the presence
 *    of a  client and also  the unexpected disappearance of  a client
 *    and  by clients  to learn  the schema negotiated by  the server
 *    after it receives  the initial heartbeat message  from a client.

And more...

Mike

On Tuesday, October 15, 2019, 06:45:44 AM CDT, Bill Somerville 
 wrote:



On 15/10/2019 05:35, Black Michael via wsjt-devel wrote:
> The description in the WSJT-X source is using the terminology of
> WSJT-X as the server and anybody talking to it as clients.

Mike,

where are you seeing that? It is not correct and if that is what is
stated it need changing.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Black Michael via wsjt-devel]

Although the definition is a bit nebulous  WSJT-X is the thing providing data 
and services which makes it a server in my book.  WSJT-X knows nothing of the 
the "clients" connected to it other than the schema number.  Clients can tell 
the server to do a few things.  It's just like a real-time database.Whatever 
floats your boat as to what to call them.  I never worry about that 
terminology.  In the TCP world server is always the one accepting connections 
and client connect to them.  In UDP it's bidirectional and neither piece is 
actually required which leads to confusion.  If this protocol used TCP WSJT-X 
would definitely be the server.
Mike

 

On Tuesday, October 15, 2019, 09:06:47 AM CDT, Michael Pittaro 
 wrote:  
 
 
On Tue, Oct 15, 2019 at 9:34 AM Black Michael via wsjt-devel 
 wrote:
>
> NetworkMessage.hpp -- several places.  Though after reading some more 
> descriptions it does seem to free flow back and forth as to who is client and 
> who is server.  The message aggregator is referred to as a servernot sure 
> whyin my book a server is the one piece that can run by itselfclients 
> aren't required.  Clients are useless without the server.   I think the code 
> comments were written to be very generic as the client/server relationship is 
> very much message specific to In/Out.   UDP protocol doesn't really have a 
> cliient/server architecture...just a protocol that rides on it.  You could 
> just as well replace client/server with "program and another program".
>
This is what tripped me up as well.   I didn't find the code or description to 
be wrong.  It's fairly clear about client and server roles.  It just never 
points out that wsjt-x is a 'client', and it's easy to miss that, since the UI 
says 'UDP Server.'   

mike, kj6vcp
___
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

Re: [wsjt-devel] UDP Client / Server frame of reference

[Michael Pittaro]

On Tue, Oct 15, 2019 at 9:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
>
> NetworkMessage.hpp -- several places.  Though after reading some more
descriptions it does seem to free flow back and forth as to who is client
and who is server.  The message aggregator is referred to as a
servernot sure whyin my book a server is the one piece that can run
by itselfclients aren't required.  Clients are useless without the
server.   I think the code comments were written to be very generic as the
client/server relationship is very much message specific to In/Out.   UDP
protocol doesn't really have a cliient/server architecture...just a
protocol that rides on it.  You could just as well replace client/server
with "program and another program".
>

This is what tripped me up as well.   I didn't find the code or description
to be wrong.  It's fairly clear about client and server roles.  It just
never points out that wsjt-x is a 'client', and it's easy to miss that,
since the UI says 'UDP Server.'

mike, kj6vcp
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Michael Pittaro]

Thanks, Bill,

This is the enlightenment I needed.  I'll make it a point to implement
multicast support correctly.

mike, kj6vcp

On Tue, Oct 15, 2019 at 7:38 AM Bill Somerville 
wrote:

>
> Hi Mike,
>
> the terminology of client and server are somewhat loose in UDP protocols
> but with the WSJT-X UDP protocol WSJT-X is definitely a client and any
> application wishing to interoperate with WSJT-X is a server. The
> interoperating application should listen on a well known address and port
> which is the address and port configured in one or more instances of WSJT-X
> via "Settings->Reporting->UDP Server", i.e. many WSJT-X instances (clients)
> interoperate with one (or more, see below) servers listening on well know
> address and port pairs.
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Black Michael via wsjt-devel]

NetworkMessage.hpp -- several places.  Though after reading some more 
descriptions it does seem to free flow back and forth as to who is client and 
who is server.  The message aggregator is referred to as a servernot sure 
whyin my book a server is the one piece that can run by itselfclients 
aren't required.  Clients are useless without the server.   I think the code 
comments were written to be very generic as the client/server relationship is 
very much message specific to In/Out.   UDP protocol doesn't really have a 
cliient/server architecture...just a protocol that rides on it.  You could just 
as well replace client/server with "program and another program".
 * it  is essential  that clients  and * servers  of  this protocol  can  agree 
 on  a common  scheme.   The * NetworkMessage  utility classes  below exchange  
the schema  number * actually used.  The handling of  the schema is backwards 
compatible * to  an  extent,  so  long   as  clients  and  servers  are  
written * correctly. For  example a server  written to any  particular schema * 
version can communicate with a client written to a later schema.

 *    message is intended to be used by servers to detect the presence *    of 
a  client and also  the unexpected disappearance of  a client *    and  by 
clients  to learn  the schema  negotiated by  the server *    after it receives 
 the initial heartbeat message  from a client.
And more...
 Mike
On Tuesday, October 15, 2019, 06:45:44 AM CDT, Bill Somerville 
 wrote:  
 
 On 15/10/2019 05:35, Black Michael via wsjt-devel wrote:
> The description in the WSJT-X source is using the terminology of 
> WSJT-X as the server and anybody talking to it as clients.

Mike,

where are you seeing that? It is not correct and if that is what is 
stated it need changing.

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

Re: [wsjt-devel] UDP Client / Server frame of reference

[Bill Somerville]

On 15/10/2019 05:35, Black Michael via wsjt-devel wrote:
The description in the WSJT-X source is using the terminology of 
WSJT-X as the server and anybody talking to it as clients.


Mike,

where are you seeing that? It is not correct and if that is what is 
stated it need changing.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Client / Server frame of reference

[Bill Somerville]

On 15/10/2019 04:47, Michael Pittaro wrote:
I've been playing around with the UDP server capability in wsjt-x, and 
I think I've got most of the lower level details figured out. However, 
I got blocked on the schema negotiation part, which raised a deeper 
question.


I have been assuming wsjt-x is a server, and my code is a client.  So 
I sent heartbeats like a client, and I was expecting some sort of 
response back, which never arrived.  I definitely see traffic 
(heartbeats, decodes, status, etc.) from wsjt-x, using the WSJT-X 
client id.


Digging deeper, it seems wsjt-x is acting more like a client.  The 
docs also imply that.  For example, The location message is described 
as in, allowing a 'server' to set the location.  Logged ADIF is 
described as out, being sent to servers when a QSO is logged. The 
example message aggregator is also a server, listening to wsjt-x and 
other clients.


I think I'm just missing something obvious here in terms of the frame 
of reference for client and server, and what the client/server model 
looks like.  Should my code act like a client or a server?


So far, I'm I'm using unicast, with just wsjt-x and my code running.

mike, kj6vcp



Hi Mike,

the terminology of client and server are somewhat loose in UDP protocols 
but with the WSJT-X UDP protocol WSJT-X is definitely a client and any 
application wishing to interoperate with WSJT-X is a server. The 
interoperating application should listen on a well known address and 
port which is the address and port configured in one or more instances 
of WSJT-X via "Settings->Reporting->UDP Server", i.e. many WSJT-X 
instances (clients) interoperate with one (or more, see below) servers 
listening on well know address and port pairs.


With unicast UDP there can only be one server per address and port pair 
(UDP broadcast does not have that limitation but has other severe 
routing limitations that make it unsuitable for the WSJT-X protocol), 
this is a fundamental limitation of IP addressing and information 
transport. WSJT-X expects servers to implement multicast group UDP 
address membership, this removes the limitation of there only being one 
server per address and port pair. Unfortunately almost all applications 
that have so far been written to interoperate with WSJT-X have failed to 
implement multicast group membership which means that they are not good 
citizens in the WSJT-X protocol because they consume messages that would 
be sent to all multicast group members. This means that using such an 
application precludes other applications joining the party without 
over-complex, and only partially successful, message forwarding 
arrangements.


The reference applications provided with WSJT-X (message_aggregator and 
udp_daemon) do support multicast group membership and can be easily used 
to demonstrate the protocol working with multiple WSJT-X instances *and* 
multiple interoperating sever applications. To do this simply set the 
UDP server address in all WSJT-X instances to a multicast group address 
of suitable scope, e.g. 239.255.0.0 will work on the local sub-net which 
includes multiple servers and clients on a single host. The service port 
number choice for multicast is no different than for unicast and the 
default 2237 is fine so long as no unicast servers within the scope are 
listening on that port. With message_aggregator the multicast group 
address is set in the UI, with udp_daemon it is a command line argument 
(use the -h command line option for usage information).


With respect to Heartbeat messages, they are bidirectional but not 
required in the server to client direction, currently the only action is 
taken by WSJT-X on receipt of a Heartbeat message is initial schema 
negotiation, other than that they only keeping the protocol alive by 
informing that the server is still alive and kicking. Servers can choose 
to send regular Heartbeat messages to each client they are aware of but 
it is not a requirement, sending Heartbeat messages at 15 s intervals 
would not be unreasonable if servers choose to do so. Note that traffic 
from servers to clients is not multicast since all messages to clients 
are specific to that client. Traffic sent from servers shall be sent to 
the sender address and port pair gathered from a prior message receipt  
from the client, this is normal IP messaging as used by any server 
application serving content to a client. WSJT-X instances do not listen 
on the multicast group address, that is the role of the servers.


With respect to the schema number, firstly the schema number does not 
define the message types or fields, it is there to define the low level 
serialization of field contents on the wire. The schema number will only 
be incremented if we need to include a new field data type that is not 
defined by the current schema and that in turn is defined by the Qt 
serialization formats for the Qt types that we use on the wire. I should 
add that more than one 

Re: [wsjt-devel] wsprnet abandoned

[Tom M0LTE]

It would be awesome if the subdomain all the spots get submitted to was
redirected to some community-funded broker server, and some kind of pub-sub
messaging set up for subscribers to be able to consume the data in
real-time, on a par with the wsprnet.org site. Spots could still get
proxied to the existing site. That would really help open the dataset up to
deeper real-time analysis, which is extremely valuable data for the amateur
radio community.

Tom M0LTE

On Tue, 15 Oct 2019 at 04:42, Eric NO3M  wrote:

> Onno
>
> My frustration is specifically with the seeming unwillingness of the admin
> team to recognize the serious system issues that have plagued the site for
> the last two years (at least).  If this assumption is inaccurate, then my
> apologies, as it is based on the comments made by the admin that posted to
> this list and taken as the position of the rest of the admin staff.
>
> Countless offers for help have been made by individuals, either in
> expertise/time or monetary.  It seems at this point a fresh perspective and
> solution is warranted, as the status quo and temporary band-aides that have
> been performed in recent times only alleviates the issues for a short
> period of time.
>
> The rest of my Email just stated observational facts.  At the end of the
> day, I could care less if the site works or not, I still have my own spots
> in the locally running WSJTx to utilize as needed.  But other folks use the
> mass collected data for many purposes and it's become more difficult to
> interact with and acquire that data and parts of the site.
>
> Also, this has nothing to do with the map
>
>
> 73 Eric
>
>
>
> On 10/14/19 10:39 PM, Onno Benschop wrote:
>
> Eric, the frustration in your email is visceral and leads me to one
> question:
>
> When did you last pay for an SLA in relation to wsprnet?
>
>
> --
> finger painting on glass is an inexact art - apologies for any errors in
> this scra^Hibble
>
> ()/)/)() ..ASCII for Onno..
>
> On Tue., 15 Oct. 2019, 08:37 Eric NO3M,  wrote:
>
>> This kind of ignorant response is frankly infuriating and in itself shows
>> why wsprnet.org is going to hell to put it kindly
>>
>> I am very active in the LF/MF community and WSPR is heavily used for
>> propagation studies, realtime band opening indication, etc.  Ask anyone in
>> at least the US and VK LF/MF community what they think of wsprnet.org...
>>
>> There are definitely spots that never make their way to the database,
>> numerous in fact.  The poor system performance is a recurring topic in the
>> LF/MF chat group.  Almost nightly someone complains about slow response or
>> that the database part of the site just simply will not load.  You can't
>> definitively say all spots are being imported into the database... from the
>> site's vantage point there is no way of knowing what is missed due to the
>> site being unreachable when those lost spots are coming in.
>>
>> The "database" part of the site is very often extremely slow to load or
>> never loads at all.  Eventually, without fail, on a daily basis, the page
>> will fail to load when left open in a browser tab when it attempts to auto
>> refresh.
>>
>> I understand you are not part of the technical team, but perhaps the ones
>> responsible can be given the message loud and clear and not continue to
>> assume all is fine.  The site (specifically the database infrastructure)
>> needs serious intervention.  The folks that are responsible for maintaining
>> the site's functional integrity have failed miserably.  Time to step up or
>> pass the responsibility on to a competent team.
>>
>> 73 Eric NO3M
>>
>>
>>
>>
>>
>> On 10/14/19 3:45 PM, Erwin Serle via wsjt-devel wrote:
>>
>> Not sure why you come to these conclusions, the website is not slow, it
>> is not abandoned and the spots enter the database nicely.
>>
>> The map issue is explained in the wsprnet org forum with the appropriate
>> solution as well.
>>
>> Users are managed steadily albeit sometimes slowly as I am probably the
>> only user admin doing any work on it at all most of the time.
>>
>> The other admins focus on keeping the site itself up and running and
>> solving the more technical issues.
>>
>>
>> Happy to give more insight if needed:
>>
>> Erwin,
>>
>> PE3ES/F4VTQ
>>
>>
>> On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger 
>> wrote:
>>
>> Hi,
>>
>> This is probably not the right place for this issue, but all other
>> options didn't get attention unfortunately.
>>
>> Over the past months and years, wsprnet got continuously slower, as more
>> and more people used the service.
>> Since a few months, wsprnet got unreachable for minutes multiple times a
>> day. It is common that database requests time out.
>>
>> wsprnet does also regularly lose wspr spots, because it is overloaded.
>> Since a week now, the map on wsprnet.org doesnt work anymore.
>> The official wsprnet e-mail is refusing e-mails since at least one year(!)
>>
>>
>> Over the past months, there have been countless