From: interlinked.us@gmail.com   
      
   I have a few development-related questions, not explicitly about SBBS, but the   
   architecture of SBBS and other BBSs in general (mainly for Digital Man, but   
   any insights welcome).   
      
   I've been contemplating writing my own BBS software for a while, from the   
   ground up, in order to better accomplish certain objectives. I have a custom   
   board that's mainly a hacked hodge podge of shell scripts that I haven't   
   touched in years... at the    
   time I wasn't interested in writing a real BBS but I think it makes more sense   
   now. SBBS is neat as well but I'd like to write something of my own.   
      
   As background, I have a fair amount of C development experience working on   
   large, multi-threaded programs, sockets, shared object modules,    
   seudoterminals, etc - a lot of the relevant systems programming. However, I'm   
   a bit stuck on conceiving the    
   optimal architecture for something like this, or how SBBS is architected. I'm   
   familiar with server processes that run as a daemon where other "client"   
   processes can connect to it using a socket (commonly Unix domain socket) to   
   get a "remote" console (   
   remote as in remote to the actual daemon process). Each TTY is handled by a   
   separate "remote" process communicating with the daemon process via a socket,   
   and the daemon process has all the actual logic, loads all the dynamic   
   modules, etc.   
      
   One thing I'd like to preserve is being able to dynamically reload modules. If   
   you have a single daemon process loading modules, you can dlclose and dlopen   
   them again and basically hot reload part of your program. The client processes   
   don't touch that,    
   so you can reload functionality while the program is running and users are   
   connected.   
      
   I'm not 100% sure how this best translates into the BBS world. If you take   
   something like ncurses, ncurses really does not like multithreaded programs (I   
   know there is a version that supports it, but it's really not a widely   
   supported configuration). So    
   I'm questioning the aspect of "everything" actually being in a single process,   
   and wondering if there's some other architecture programs like SBBS, for good   
   reason, that works better.   
      
   I've browsed through a lot of source code, and I understand some different   
   things that are going on, but SBBS is so large that I haven't gotten a crisp   
   understanding of everything this way. So kind of at a high level, I'm curious   
   if you could discuss a    
   little bit about some of the following things:   
   - Client server model: process/thread hierarchy, how remote TTYs   
   pseudoterminals interact with the main server process (what processes and   
   threads are involved for a TTY)   
   - Usage of sockets vs. pseudoterminals in SBBS   
   - How ncurses is used (all in one thread, all in separate processes, etc.)   
      
   As a specific example, say a new client connects (say via telnet), so the SBBS   
   telnet thread/process spawns a new thread/process for that, and the main   
   process gets a handle to the slave PTY. (I have to imagine the PTY is needed,   
   as opposed to just a    
   Unix domain socket). SIGWINCH is per-process, so now you have SIGWINCH going   
   to the entire main process on a resize (ouch?). And if you want to run   
   ncurses, unlike normal text I/O, you can't just do that in the threads in the   
   main process handling the    
   remote clients.   
   Obviously I'm sure that's not quite how SBBS works but an example of things   
   I've been pondering.   
      
   Again, I'm not asking about how to program anything specifically, just looking   
   for some thoughts and explanation on the architecture itself. Sorry if these   
   questions are a little windy, but I think any insight you might have would   
   really help, and the    
   rest will probably make more sense at that point...   
      
   Thanks!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)