Today, I had a thought that stuck to me for a while. It first started with the Yahoo! frontend, which I made bind to the fallback ports, all expect for port 80, which the server was already using for HTTP communication, and then it branched out to overall network traffic and how it’d make sense to balance it out somehow. Regardless, both ideas led to this idea: finally distributing Escargot onto several servers.
How it’d work is something like this. Let’s say we have 16 servers, ranging from letters A - P, each with certain frontends enabled and certain others disabled:
- Servers A - E host a dispatch server for the MSN frontend.
- Servers F - I host notifications servers for the MSN frontend, but Servers G and I also host the Yahoo! frontend.
- Servers J - P host the necessary switchboards for the MSN frontend.
When you connect to
m1.escargot.log1p.xyz on the MSN port, for instance, you’ll be taken to one of the servers from A - E, which during the authentication process, will transfer you to one of the servers from F - I, which are the notification servers listed earlier. When you connect to one of those notification servers, if they aren’t full, you’ll be able to continue the authentication process and log on to MSN. Then when you want to request a switchboard server to initiate a chat session, an IP to one of the servers from J - P will be sent in reply.
If you connect on the Yahoo! port, you’ll be directly taken to either servers G or I, which will let you authenticate to the Yahoo! service and allow you to see your contacts’ presence and talk to them in that one session.
In regards to HTTP servers, those will be separate from the frontend-specific servers and act independently. However, they will still host services for specific frontends.
Now that the plan’s been laid out, now there’s federating things like user presence, messages, and session data (e.g, authentication tokens), I don’t exactly know how to do this, as I haven’t had much experience with networking, but rest assured, either I or @valtron will find something that helps with our federation needs. There’s also switching database engines, since SQLite wasn’t intended for remote use, as all of these servers will need a way to access user data in one central location, and either way, it probably won’t keep up with Escargot’s slowly-but-surely growing popularity (@valtron told me that Escargot’s SQLite database file is 150MB!)
When we get to implementing this kind of architecture, it’d be worth the hard work, and it’d improve Escargot’s performance a lot. And lower the amount of booting we have to endure.