Subj : Re: New in this
To   : Michiel van der Vlist
From : Ward Dossche
Date : Sat Dec 08 2018 22:16:04

Michiel,
 
Mv> I was not harping on D'Bridge, I was trying to pinpoint the source of the
Mv> problem by elimination. The inner workings of D'Bridge have always been
Mv> treaetd as if they are state secrets. So I had to work on a minimum of
Mv> knowledge.
 
That is a slight exageration.
 
D'Bridge is exactly as Kees describes. It generates an outbound-queue in a base-36 format. This is how it was made to work "here" and still does ...
 
DBUTIL moves everything for a specific client into a dedicated directory,
in this case 2:250/1
 
  c:
  cd c:\db
  dbutil move 2:250/1 C:\DB\BINKD\22501
 
Deleting a trailing FLO-line
 
  c:
  cd c:\db\binkd\22501
  del ????????.flo
 
Check if there is content in that directory
 
  c:
  cd c:\db\binkd\22501
  dir /a-d/b 2>nul >nul
  if errorlevel 1 goto end
 
Unpack possible packed content into pkt-files
 
  c:
  cd c:\db\binkd\22501
  call c:\db\bat\unpack.bat
 
Create FLO-file of whatever content is in the dedicated directory and let BINKD do its thing zith it ...
 
  c:
  cd c:\db\binkd\22501
  d:\soupgate\genflow 250 1
  copy ????????.flo c:\binkd\outbound
 
  :end
 
You know how to read a batch file.
 
Mv> The way it looks now, is that the version of binkd that Ward used was the
Mv> exception. Despite the fact that it showed the IPv6 compile option was
Mv> used, it would not do IPv6. So replacing it was NOT useless in tracing
Mv> the problem.
 
This is the version I am about to use now ...
 
*****************************************************************************
Binkd 1.1a-99 (Jun 25 2018 22:50:08/Win32)
Compilation flags: mingw32, zlib, bzlib2, perldl, https, ntlm, amiga_4d_outbound, bwlim, ipv6, af_force.
Facilities: fts5004 ipv6
*****************************************************************************
 
FYI.
 
 \%/@rd

--- D'Bridge 3.99 SR40
 * Origin: When there's an elephant in the room, introduce him (2:292/854)

.