[wt4hq] IARU HQ drawing closer....

[Laurent HAAS - F6FVY]

Hi Mario et al.

Le 20/05/2012 15:51, Mario Lorenz a écrit :

> So, the obligatory question is: Is there anything new planned for
> Win-Test HQ versions this year ? I note that not much development
> has happened over the last year, so hopefully not much happens,
> especially no incompatible network protocol revision ?

As no new protocol version has been introduced since last year IARU 
contest, the HQ 2011 version is compatible with the current official 
version of Win-Test.

The WtTunnel (Client and Server) are also still OK.

Reminders - Download links :

wt-4.5.2-HQ.exe : http://www.win-test.com/hq05/download/wt-4.5.2-HQ.exe
(installer)
wtTunnel-1.12.exe :
http://www.win-test.com/hq05/tunnel/client/win32/wtTunnel-1.12.exe (exe
only - no installer)
wtTunnelSrv-2.4 : http://www.win-test.com/hq05/tunnel/server/ (several
flavors available)

Reminders :

- One wtDxTelnet ONLY per connected cluster per LAN
- One wtTunnel (client) ONLY per LAN
- To enable sync on the WAN, one WT must be set as bridgehead on each
LAN (Options / Interfaces / Network advanced settings). CAUTION : One
bridgehead per LAN.

> I've also found the WtTunnelClient source on the wintest web server,
> dunno if this is new or if I just had overlooked it in the past.

I think it is available since the beginning ;-)

> Question: Which C compiler version is this usually compiled with ?

I guess it is Visual C++ 5.0 (VS 1997). It was the compiler that was 
used for WT until version 4, and these auxiliary programs have not been 
migrated to the current environment (VS2005) for some reason.

> I've looked at the source and see an explanation for a bug that has
> plagued us in the past, so I suggest this be fixed:
> When you have a busy LAN, and the tcp connection to the server
> is temporary lost and reconnected, it happens that at the login stage,
> before the login data is sent, tunnel data is being sent, which would
> then upset the login process at the server.
>
> Suggested fix is to condition the m_pTunnel->Send(str) in
> OnLanNetworkReceive() on m_nTunnelState == CONNECTED and just
> for avoidance of Race Conditions move the m_nTunnelState=CONNECTING to
> the beginning of ConnectToTunnelSrv()...

It seems to be a good catch, Mario (as usual with you ;-) ). I'll try to 
find the time to check and built a new version next week, to make it 
available quickly. You'll be informed on this list.

73

Larry - F6FVY