Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    SYNC_SYSOPS    |    Synchronet Multinode BBS Software Suppor    |    33,243 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 30,738 of 33,243    |
|    Rob Swindell to GitLab note in main/sbbs    |
|    nntpserver not able to read articles aft    |
|    09 Nov 24 20:17:19    |
      TZUTC: -0800       MSGID: 56743.sync_sys@1:103/705 2b964776       PID: Synchronet 3.20a-Linux master/9d3a8113d Nov 04 202 GCC 12.2.0       TID: SBBSecho 3.21-Linux master/b8260ae62 Nov 08 2024 20:27 GCC 12.2.0       BBSID: VERT       CHRS: ASCII 1       https://gitlab.synchro.net/main/sbbs/-/issues/814#note_5956              The actual problem here appears to be the opposite of the original title       "nntpserver not able to read articles after files closed":       When the nntpservice has a message base *open*, it uses a short (10 second)       timeout while waiting for a command from the NNTP client (news reader). When       there is no message base open, nntpservice still uses the long-time 300 second       (5 minute) timeout while waiting for a command.              The additional detail was provided by Nick (Accesion) via DOVE-Net:       ```       Nov 09 20:25:33 reaper synchronet[608]: srvc 0056 NNTP       [Fidonet.SYNC_SYSOPS] cmd: A       Nov 09 20:25:33 reaper synchronet[608]: srvc 0056 NNTP !unknown command       Nov 09 20:25:33 reaper synchronet[608]: srvc 0056 NNTP       [Fidonet.SYNC_SYSOPS] cmd: RTICLE 14218       Nov 09 20:25:33 reaper synchronet[608]: srvc 0056 NNTP !unknown command        ```              The client command appears to have been broken into two parts by       Socket.recvline().              I was able to reproduce this and narrowed it down to this situation:              nntpservice.js is waiting for a command from the client, with a short (10       second) timeout because there's a message base already open (and we want to       close it relatively quickly when there's no activity from the client). If the       news client user waits 8-9 seconds between commands, the first character of       the command might arrive (and be received) just before the timeout is to       expire. It's an edge case that's new. Socket.recvline() didn't use to behave       this way.       https://gitlab.synchro.net/main/sbbs/-/blob/f46ba4d2df43b78a66f2       670875eec5002765dc8/src/sbbs3/js_socket.c       --- SBBSecho 3.21-Linux        * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)       SEEN-BY: 90/1 103/705 105/81 106/201 124/5016 128/187 153/757 7715       SEEN-BY: 154/10 30 203/0 218/700 221/0 226/30 227/114 229/110 114       SEEN-BY: 229/206 317 400 426 428 470 550 700 705 240/1120 5832 266/512       SEEN-BY: 280/464 5003 5006 282/1038 291/111 292/8125 301/1 320/219       SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124       SEEN-BY: 467/888 633/280 712/848 770/1 5020/400 8912 5054/30 5075/35       PATH: 103/705 280/464 460/58 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca