[WT-support] DA0HQ and Win-Test 3.0.6-hq

[Mario Lorenz]

Hi Larry,

> >  That QSO simply ought to be ignored, in any case the Contest should
> >  have been loaded.
> 
> We have to think abt that, even it is not so obvious.
... and I still wouldnt know how to currently recover the log.
Fortunately, the station in question was only a support station with no
QSOs being entered there.
> 
> Actually, loading an "old" log while joining the network is the most 
> dangerous thing, because sync starts immediatly and all logs become 
> corrupted ! We already circumvent the name problem.

Yes. Again, this is something an unique id might prevent. I'd be
thinking along the lines of one network control file that would have
to be distributed manually (or explicitly requested from a certain named
station) that would include the UUID for the contest, and perhaps even
some password that would be used to authenticate dangerous remote
commands like CLEARLOGALL to come only from one management station.
In a "regular" contest this would be of little use, but on a big remote
setup like the IARU contest it is impractical to go through all
computers yourself, or shout into the room...

> >One designated station could be allowed to sync
> >via the tunnel (and since all other stations would sync to that station
> >on the lan, this should be sufficient ?)
> 
> Not very easy to manage (because it needs the user to set such things 
> and you know that in such a configuration (HQ team), some teams are not 
> very aware - to say the least - of these things). But, of course, it is 
> a good way to reduce traffic. There are also other ideas around (read 
> proxies).

Yes, this pretty much would be a proxy setup. My idea might be off by
miles because I don't know the synch protocol in detail, but on
first glance, it seems to me that stations publish currently logged
QSOs by IHAVE, then stations ask for QSO data with NEEDQSO, and then
the sending station selectively sends missing ones using ADDQSO.
Now, what would happen if the wtTunnelClient on the LAN side simply
dropped all IHAVE and NEEDQSO frames by default, but had a field where
one could designate one station in the local network whose frames would
pass ?

Main idea would be to concentrate HQ logic only in the tunnel client,
because that is the only place where it is needed (no other contest even
runs it...)

> We deliberately choosed un-acked broadcasted frames to ease networking 
> for non-geeks with no central server. It also requires much less 
> resources. And it also allows "third-party" softwares to easily join the 
> party (we are even freely providing a DLL to be included in various 
> language projects). IMHO this architecture is totally acceptable in a 
> contest station LAN. The sync feature (to be improved - I totally 
> agree), prevents "QSO loss", which is the most annoying, especially when 
> the LAN is not "solid rock" (read WiFi, HF-disturbed, etc.) !

I think you got the priorities wrong. QSO loss is annoying, but not 
critical - you can merge the logs manually later or have them merged by logsync.
Missing/bad communication _during_ the contest (ie: "Hey 20CW, there's
this rare multi on 14007") is what will cost points in the end.

Central server also is not a requirement. Each station knows which other
stations are on the net (due to STATUS), so a station just needs to send
an ACK to the sending station on receipt of a GAB. The sending station
would count the receipts and flash a warning if there were less than
expected. No retransmit, no central server, should be reasonably simple.
About the third party DLL, I'd be interested in that. Tho we discussed
it before; I'm a linux geek, so I'd prefer source, or a documented
network protocol.

> I'm not very convinced that status frames are a big waste of BW, but we 
> can think abt such an option. In all cases, I'm a pretty skeptical on 
> the ability to pass WT traffic on such very low BW links.

They are. Assume, for example, a 40 computer network and 
a 30000 QSO count, during a 24 hour period. The math figures to one
ADDQSO every three seconds, and two STATUS messages per second.
Assuming ADDQSO is roughly twice as big as STATUS, thats still a 
1:3 ratio, ie. 75% of the total bandwith is for STATUS.
(always of course assuming sync off, and always assuming a low bandwith
site-connection link. I totally agree that in a local LAN, the
bandwith used is insignificant. Thus, consistent with my earlier
proposal, you should not cut down on sending the frames in WT, but
the tunnel client should cut down distributing them thru the tunnel.

> >AAARGH. And where, pray tell, were these commands documented ?
> 
> You should find them in the release file. Well, I think so ;-)
> 
Ok. Guess I'm ignorant. Could it by chance be that this was
implemented in one of the releases between 3.0.0 and 3.0.5, and 
these release notes were not published? I still can't find any mention
of them...


> >You know, when I noticed the server problems, it still took me quite a
> >to call up all our stations and make sure that sync was really
> >turned off, on all computers... (that the menu setting is inversed, ie, the
> >tick is visible when logsync is _disabled_, didnt help communications
> >either)
> 
> Don't worry, it also happened @ TM0HQ, even if we had several testing 
> evening sessions during the previous week of the contest.

But you knew how to remotely disable SYNC...

> 
> We thought that we could break off after WRTC and IARU, but it seems we 
> will have to wait a bit more to rest ;-)
> 
Oh, I'm all in favour of giving you a break, after the problems are
fixed :)
I'd even prefer if the software wouldnt change for a month before
IARU, that helps cutting down on last minute coordination ("which
version do we use again?" and registration problems :)

Regards,

Mario

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
* This virus needs Windows95 to run!