[wt4hq] Patch for wtTunnelSrv

[Mario Lorenz]

Am 20. May 2007, um 08:55:02 schrieb Olivier F5MZN:
> Hello,
> 
> The main improvement consists in the "autolearning route and filter 
> feature", which:
> 
> 1. learn which wtTunnel client a station is located behind
> 2. when a protocol is sent to a specific station (like the QSO 
> synchronisation ones), only forward this protocol to the wtTunnel (aka 
> to the LAN) the station is behind

Thats on the server side. I was wondering if you included something
like this on the client side as well.

> I am no against providing the source code of the wtTunnel software on 
> conditions that:
> 
> 1. if someone made improvements in, this must be shared with the WT 
> community
> 2. the patched source code still much work with my old Visual C++ 5.0! :)

I can't comment on VC++5 compatibility, since I am mainly a linux guy,
and for windows work I have only mingw and VC++2007 (Express) to test.
I would have written my own client long ago if I were sure about
the network protocol. I think I've understood most of it, but not all
of it.
> If you do that way, every stations will be penalized. IMHO, it is 
> acceptable to reduce the amount of Status Frames for the "low bandwidth" 
> (or "limited bandwidth" due to the cost) but it is not relevant others 
> when an "unlimited high bandwidth" inet connection is available.

No, I think you got it backwards.
As I reported last year, after we turned off logsync for it making a
mess out of the network, the absolute majority of the traffic is
status frames. These status frames serve the purpose of "i'm still
alive' and the current frequency. The current frequency for RUNNING
stations only rarely changes. The current frequency of support stations
is rarely important. broadcasting all these frequencies through
the net every 20 seconds is thus unneccessary bandwidth. Reducing it to,
say 2..3 mins OR QSY, would be fine and cut down drastically on that
traffic. I have thought about filtering that on the server side,
but it needs to be done on the client side (or requires changes in WT)
because simply filtering the STATUS packets makes the station disappear
in the other people's station lists etc. So the receiving client would
keep track of the stations too, and recreate STATION frames on the local
LAN, every 20 seconds.
Reduction of unnecessary traffic does not penalize stations. Sending
the unnecessary traffic is a luxury that "unlimited high bandwidth"
stations can afford.
Ideally, a 9k6 packet radio link is my measure of "good baseline".

> 
> If so, this need to limit this traffic (for some stations) at the server 
> side, not in wtTunnel. This needs too much work than I can spend on this 
> project but any patch will be welcome!

On the assumption that for the slow station, the client-server link is
expensive, the filtering again has to be done in the client, because
traffic is unneccessarily transmitted to the server, clogging the
uplink.

> 
> Another way for limiting the trafic could be to filter Status Frames for 
> some support station. This could be done either at the wtTunnel side or 
> at the WT side. We already improved WT addind a way to limit the "QSO 
> synchronization broadcast" from some station of the LAN but TBH I don't 
> remember where Larry added the option menu for in WT...

Yes, I have seen that in the network options. But as you say, any
changes here also penalize stations on the local LAN, absolutely
unnecessarily. The filtering intelligence therefore ought to go to the
client.

Best regards,

Mario

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
"Your mouse has moved. Windows NT must be restarted
 for the change to take effect. Reboot now ?   [ OK ]"