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 t
hat 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 s
everal 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
|
