[wt4hq] TunnelClient doesn't filter, kills uplink

[Mario Lorenz]

Hi,

After several delays, I finally got around setting up a test network
consisting of at least several nodes.
I observed exactly what I feared:
The tunnel client (v 1.7) does not include the station name learning
logic that the new server has. This has the following effect:
Assume a site with a few computers, and a GPRS uplink (due to faster
modes not being available). Logsync being enabled.
Late in the contest (say, 20k QSOs), one of the computer dies, and is
duly replaced with a spare. That spare doesnt have any log, so when
it comes up, it will start syncing the whole log.

Now, if that computer happens to sync to some remote computer, thats
1.6Megs that will have to go thru the Link, effectively killing it for
5..10 minutes. I can't comment on wheter and how often this will hapen
since I haven't fully understood the protocol. Even if it does not
happen, and it syncs the log from a PC on the local LAN, all that sync
traffic is uplinked to the server by the client. The server will then
throw that data away, so that uplink is completely unnecessary.
Now, all that sync data on the LAN will clog the uplink, impacting
regular QSO flow.

Steps to reproduce: Take your last year's log in one station on the lan,
set up a remote tunnel server somewhere and set up the client, then
connect a new PC on the same LAN, opening an empty HQ log there, and let
it sync. Watch bandwith and response of your uplink.
(without knowledge, but I assume it might get worse if the log was not
empty, but partial (ie with holes), due to the additional IHAVE traffic
instead of only blazing ADDQSOs)

Mario

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
The deorbiting of MIR was brought to you by radio FFH and MIRcrosoft, your
specialist for controlled crashes!  (local radio station, on the very day)