From Newsgroup: alt.bbs.synchronet

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, pseudoterminals, 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!
--- Synchronet 3.20a-Linux NewsLink 1.113
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

Re: BBS architecture questionsã By: BBS Coder to alt.bbs.synchronet on Sat Nov 05 2022 03:51 pmãã > From Newsgroup: alt.bbs.synchronetã >ã > 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,ã > pseudoterminals, 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.ããSynchronet is open source. You shouldn't be "stuck" with regards to determining how its architected.ãThere is a (Windows-centric) architecture diagram here however:ãhttps://wiki.synchro.net/dev:architectureãã > 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).ããWell unix domain sockets are "local", not "remote", but okay.ãã > 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.ããThis isn't any architecture I'm familiar with.ãã > 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.ããSBBS v3 runs as a single multi-threaded process. It doesn't use ncurses within that process.ãã > 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)ããThe servers are part of a monolithic process (not client/server) that includes several TCP servers.ãã > - Usage of sockets vs. pseudoterminals in SBBSããPseudoterminals aren't used.ãã > - How ncurses is used (all in one thread, all in separate processes, etc.)ããIt's not.ãã > 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.ããSBBS does not use a PTY in this way.ãã > (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.ããThe SBBS terminal server doesn't run/use ncurses.ãã > 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!ããNo problem!ã-- ã digital man (rob)ããThis Is Spinal Tap quote #24:ãDavid St. Hubbins: You're a haughty one, saucy Jack.ãNorco, CA WX: 70.6øF, 43.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã