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

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