• Door32.sys development

    From LEE WESTLAKE@2:250/6 to All on Friday, June 11, 2021 14:08:19
    Hi Guys,

    Is anyone able to confirm the following queries regarding telnet win/nix door development (Door32.sys) for Mystic:

    1) Does Mystic pass a blocking or non-blocking socket handle?

    2) With regard to point 1, is there an established standard which all BBS systems adhere to (i.e. blocking or non-blocking)?

    3) If the door changes socket mode, should this be undone prior to exit?

    4) Is the door expected to perform winsock clean-up if the client performs an impromptu disconnect?

    Any advice would be greatly appreciated.

    Best Regards

    |01°|09²²²²² |01³|09 Lee Westlake |01(aka TALIADON)
    °|09²|01°|09²|01°|09² |01³|09 TALIADON BBS |01(taliadon.ddns.net)
    °|09²|01 ³ E-Mail: taliadon-bbs@mail.com
    °|09²²²|01 ³ fsxNet: 21:3/138 ù FidoNet: 2:250/6
    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: TALIADON BBS (2:250/6)
  • From g00r00@1:129/215 to LEE WESTLAKE on Saturday, June 12, 2021 09:47:11
    1) Does Mystic pass a blocking or non-blocking socket handle?

    Blocking

    2) With regard to point 1, is there an established standard which all BBS systems adhere to (i.e. blocking or non-blocking)?

    The only standard that I know of that ever attempted to define anything was Mystic's DOOR32 and that uses blocking sockets. I assume you'd probably get blocking from most BBSes then by default, but I can't say for sure what other software does.

    3) If the door changes socket mode, should this be undone prior to exit?

    I think it'd be a good practice to do this.

    The original intention was that the socket should be duplicated before being passed to the door, but I think in practice that didn't end up being guarenteed or even done at all because of variations in operating systems (and if I am not mistaken some OSes specifically said that sockets should not be duplicated).

    I didn't have the foresight back in the 1990s to specifically call this stuff out in the DOOR32 docs unfortunately and now I forget most of the details like this. It was all pretty new back then and I was inexperienced.

    4) Is the door expected to perform winsock clean-up if the client
    performs an impromptu disconnect?

    It *might* be safe to call only when it drops but I can't say for sure without experimentation.

    If I remember correctly calling WSACleanup is a Windows specific thing and it invalidates any socket handles used by the process. For that reason I think it was not called in any case within D32 doors. Instead it let the BBS detect the connection loss and do what it does.

    Things may behave differently depending of if/when the socket was duplicated by the BBS before being passed, but I would
    operate on the assumption that the socket is not duplicated.

    --- Mystic BBS v1.12 A47 2021/06/07 (Windows/32)
    * Origin: Sector 7 | Mystic WHQ (1:129/215)
  • From LEE WESTLAKE@2:250/6 to g00r00 on Monday, June 14, 2021 12:58:57
    Hi g00r00,

    Thank you for taking the time to address each of the points raised; your comprehensive response is very much appreciated.

    Blocking

    The only standard that I know of that ever attempted to define anything was Mystic's DOOR32 and that uses blocking sockets. I assume you'd probably get blocking from most BBSes then by default, but I can't say
    for sure what other software does.

    I think it'd be a good practice to do this.

    The original intention was that the socket should be duplicated before being passed to the door, but I think in practice that didn't end up
    being guarenteed or even done at all because of variations in operating systems (and if I am not mistaken some OSes specifically said that
    sockets should not be duplicated).

    I've decided to do the extra legwork and write comm routines which work transparently for either blocking or non-blocking sockets - as winsock
    doesn't detect socket mode reliably, this solution removes the headache of socket mode altogether.

    It *might* be safe to call only when it drops but I can't say for sure without experimentation.

    If I remember correctly calling WSACleanup is a Windows specific thing
    and it invalidates any socket handles used by the process. For that
    reason I think it was not called in any case within D32 doors. Instead
    it let the BBS detect the connection loss and do what it does.

    Things may behave differently depending of if/when the socket was duplicated by the BBS before being passed, but I would
    operate on the assumption that the socket is not duplicated.

    Further testing appears to corroborate this: from what I can tell, WSACleanup is best left to the BBS.

    Again, thank you ever so much for taking the time to address these issues.

    Best Regards

    |01°|09²²²²² |01³|09 Lee Westlake |01(aka TALIADON)
    °|09²|01°|09²|01°|09² |01³|09 TALIADON BBS |01(taliadon.ddns.net)
    °|09²|01 ³ E-Mail: taliadon-bbs@mail.com
    °|09²²²|01 ³ fsxNet: 21:3/138 ù FidoNet: 2:250/6
    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: TALIADON BBS (2:250/6)