[wt4hq] Win-Test at HQ Stations

[Mario Lorenz]

Am 02. Aug 2008, um 13:20:48 schrieb John Warburton G4IRN:

> Fortunately, all our stations have broadband internet access, so slow data 
> comms isn't really a problem.

"slow" is such a relative term. Logsync on, on the local LAN, in
situations where many stations have slightly different logs (hence the
synchronisation is "complicated" can easily generate significant
ammounts of bandwith. Even with the "learning bridge" filtering
introduced to server and client last year. I would see Megabits of
Uplink traffic from Ilmenau to the central server, so even DSL hits the
limit.
Flow control in a non-homogenous network is a difficult problem; even TCP
took several attempts to get it right.
It has also been said that the only worm/virus that really could bring
the internet down would do so by modifying the TCP Flow control / Retransmit
timers of the operating systems.

> To be honest, I was hoping that the whole WT server/tunnel issue might be 
> re-thought and redeveloped. I realise that the broadcast style networking 
> isn't going to disappear, but maybe there are better ways of dealing with it 
> from a central server perspective?

I am lacking the knowledge of the network protocol (reading the traces
only gets you so far...) but my suggestion -- with least impact to the
general protocol -- mind you, HQ is the only contest I know of that
allows multi site operation -- is to modify the tunnel client and
implement configurable filters *there*, where you can filter on a 
per-station-name basis. This would allow to configure all stations to
a LOGSYNC-ON-LAN-ONLY mode (on the assumption that bandwith is cheap),
with one station per site logsyncing with only a configured ammount of
WAN peers. You could even go as far as having a win-test computer at the
tunnel server, and thus emulate a single-server sync model.

Please note that all the logsync business is only required if you have
outages on the WAN links. You will have most of the log data from the
regular ADDQSO broadcasts.
I have been debating on wheter the Tunnel clients should also reduce the
ammount of status messages sent over the WAN, and the other tunnel
clients would reproduce the missing status messages --- on a non-logsync
WAN, the status messages are the significant factor.

> 
> Any way, thanks again for your efforts at Win-Test HQ, the post-contest 
> discussion has been interesting.
> 
Uh, John, perhaps the strongest point in favour of Win-Test would be
the fact that the team using the allegedly superior log sync technology
called "StarLog" still hasnt claimed scores :)

Ducking & Running

Mario
-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
Trust the computer industry to shorten "Year 2000" to Y2K.  It was this kind
of thinking that caused the problem in the first place.