home bbs files messages ]

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