Subj : SBBS/W32 Kermit SABOTAGE
To   : MICHEL SAMSON
From : Stephen Hurd
Date : Tue Nov 16 2004 12:05 pm

  Re: SBBS/W32 Kermit SABOTAGE
  By: MICHEL SAMSON to MIKE POWELL on Tue Nov 16 2004 08:48:00

 >      That's why i refer to Rob Swindell's `Kermit.INI' as SABOTAGE!  The
 > `MS-Kermit.EXE' external file-transfer protocol-driver isn't involved, a
 > "NO CARRIER" condition would make it react (*IF* only one occured) and i
 > also tried to manage with Error Trapping relative to it but Rob rejected
 > my contribution...  It's his task to ensure that his SoftWare remains in
 > control, `SBBS' is responsible for supporting the ~FOSSIL~ interface and
 > it runs the drivers, not the opposite, after all!  I'd most probably get
 > the same results reproduced using ANY OTHER EXTERNAL PROTOCOL-DRIVER, do
 > you see the larger picture now?  This `SBBS' issue is out of my hands...

I can't seem to make sense out of this statement... here's what I get out of
this...

1) MS-Kermit.EXE has nothing to do with a problem.
2) If the user disconnects while transferring, MS-Kermit.EXE "reacts" badly
(while not being involved apparently)
3) SBBS must retain control of the socket, and is responsoble for the FOSSIL
interface to same (This is correct)
4) These same unspecified results (More on this later) would probobly happen
with other protocol drivers (they don't)

Now, these unspecified results are a "carrier hang".  Sockets have no concept
of a carrier... the socket is open until both sides close it (Honest, that's
how TCP works) you cannot do a direct FOSSIL <-> TCP interface.  If the problem
is in fact a carrier hang, the problem is with the FOSSIL driver not the kermit
setup.

Now, given that a largeish number of Synchronet BBSs run a largeish number of
FOSSIL doors regularily, one would be inclined to believe it works pretty well.
--- SBBSecho 2.10-FreeBSD
 * Origin: FreeBSD Synchronet - telnet://FreeBSD.synchro.net (1:140/17)

.