[wt4hq] Bridgehead-Bug / LogSync
Mario Lorenz
ml at vdazone.org
Thu Jul 9 17:28:13 CEST 2009
Hi Larry,
Am 09. Jul 2009, um 17:07:48 schrieb Laurent HAAS - F6FVY:
> Quick answer... Not much time...
Guess who else :)
>
> Mario Lorenz a écrit :
>
> > Observed behavior is that after the next QSO is entered on that station,
> > the QSOs show up, thus proving some sort of logsyncing taking place over
> > the tunnel despite it should not happen because there is no bridgehead.
>
> Regardless of the BridgeHead setting, "new QSOs" entered are broadcasted
> (one frame only) to all stations (LAN and WAN). The BridgeHead concept
> is only relevant for "past QSOs" sync (that generates much more
> traffic). And also, if _one_ station of the LAN has those past Q, the
> sync will be always running INSIDE this LAN.
I am not refering to the new QSOs. I am refering to the PAST QSOs that were
missing. I encountered it yesterday, and Dieter reported today, that with
BridgeHead _off_, this station somehow learned the past QSOs (that were
supposed to be lost during the disconnection). So I am currently affraid
that there is some special case / bug that allows logsync even despite
Bridgehead _off_ and therefore has the potential to melt the network.
>
> > +-SiteASTN1-------Tunnel------Server
> > ! !
> > +-SiteASTN2 !
> > !
> > !
> > +-SiteBSTN1-------Tunnel-------+
> > !
> > +-SiteBSTN2
> >
> >
> > if I want Site?STN1 and Site?STN2 to mutually logsync (in case one
> > of the PC's crashes), while turning any logsyncing via the tunnels
> > (Ie. SiteASTN1 to SiteBSTN1) off?
>
> Normally, even if wtTunnel is off, (but SYNC is engaged on these
> computers), Site?STN1 and Site?STN2 will sync. together in background.
Yes, this is the first condition, so that a station can recover locally
should it crash due to RF exposure or somesuch.
The second condition is that I would like NO logsync via the tunnel,
ever (only the ADDQSO traffic for new Q's).
It is my understanding after my last mail that this should be
achievable by enabling SYNC everywhere, but setting bridgehead = 0
on all wt.ini files, so there is no bridgehead.
Is this correct?
And would you agree that, given those settings and the drawing above,
if one tunnel goes down, and comes back up later,
and the QSOs logged on SiteASTN1 during the outage (and replicated to SiteASTN2)
show later up on SiteBSTN1 (and are dutifully replicated to SiteBSTN2),
that there must be a problem somewhere?
73s,
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)
More information about the Wt4hq
mailing list