@MSGID: 51585.sync@1:103/705 2a7d5eb8
@REPLY: 51503.sync@1:103/705 2a68078e
@TZUTC: -0700
@PID: Synchronet 3.19b-Win32 master/a2a9dc027 Jan 2
2022 MSC 1928
@TID: SBBSecho 3.20-Linux master/252b1dc3b Apr 09
2024 18:02 GCC 12.2.0
@BBSID: FQBBS
@CHRS: CP437 2
@NOTE: SlyEdit 1.75 (2021-12-11) (ICE style)
  Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
  By: Digital Man to Fzf on Mon Mar 25 2024 04:27 pm

 >> 1. When SVDM uses an inherited socket (the -h option) no telnet
 >> negotiations are done.
 DM> I`ll be committing a change here to address that - basically send the
 DM> Telnet commands to re-negotiate those operating parameters (the same
 DM> sequence that happens when answering an incoming Telnet connection).

 It addresses the local configuration but unfortunately it still
doesn`t set remote options. The remote is usually going to be in binary
mode but SVDM has the remote option set to ASCII by default. A CR from
the remote then gets held up until a second byte is sent.

 Sending a DO TX_BINARY near the WILL TX_BINARY when in ServerBinary
mode and sending a DONT TX_BINARY when not in ServerBinary but using an
external socket sets the remote options to appropriately match what SVDM is
expecting. Clients might not like having their TX binary mode turned off mid
session, but if someone is disabling binary mode on the server side they
are already doing something weird.

 It also sets the remote to binary when SVDM answers in listen
mode. At the moment it leaves the remote TX in ASCII at all times.

 DM> I added 2 new .ini settings for you to play with:
 DM> - MainLoopDelay (default: 0, set to 1+ to add CPU yield)
 DM> - SocketSelectTimeout (default: 0, set to 1+ to add CPU yield)

 These work perfectly, thanks! Just a simple 1 ms delay in the main
loop drops CPU usage to 0% most of the time.

 I also looked into the error 122 in the SBBSEXEC input_thread when
SVDM gets pushed hard, such as during a file transfer. A little
additional information on the next waiting mailslot message makes it pretty
clear. Sorry, these are going to wrap oddly:

 SBBS: !input_thread: ReadFile Error 122 (space=9411, count=0,
nextsize=10000, waiting=46)
 SBBS: !input_thread: ReadFile Error 122 (space=1211, count=0,
nextsize=5056, waiting=45)
 SBBS: !input_thread: ReadFile Error 122 (space=9635, count=0,
nextsize=10000, waiting=26)

 Etc. There`s just not enough space in the ring buffer at the time.
While these messages are harmless, the sheer number of them can help
thrash a CPU pretty good right at a time when the CPU is busy. I
changed the logging to log error 122 at a lower priority so it can be
squelched out unless debugging is needed. That further drops the CPU usage
when the SVDM is processing a lot of data.

Does your gitlab accept anonymous updates, or can I send you a diff?

Thanks again for all your work on this!

---
 ■ Synchronet ■ The Fool`s Quarter - fqbbs.synchro.net
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 50/109 103/705 154/10 218/700 221/1
240/1120 280/464 301/1 113
SEEN-BY: 341/66 463/68 467/888 712/848 3634/12
5000/111 5005/49 5019/40
SEEN-BY: 5020/715 848 1042 4441 12000 5030/49 1081
5054/8 5060/900 5061/133
SEEN-BY: 5075/128 5083/444
@PATH: 103/705 301/1 5020/1042 4441