[MUD-Dev] Re: Yet another update on threads and signals

[Chris Gray]

[Adam J. Thornton:]

 >But then, don't I need one port per process?  There's no way for me to
 >telnet to port 5019 in process 2231, for example.  So do I need to hand out
 >a random port number in some range to each process?  
 >
 >The signals avoided having to have an arbitrary number of numbered ports
 >open; I'm not sure which is the lesser evil.

Nope. I would use AF_UNIX sockets (as opposed to AF_INTERNET)
for the connections between the rooms. You access them via a filename,
such as /tmp/mud<roomnumber>. Once you have them open, they are just
like any other socket. So, the distributer would have an easy way to
find the socket for a newly created room process. The only port
exported over the internet would be the main one that users connect
at, and I would suggest it either be exported by the distributer, or
some other non-room process. When the user has been validated, and
their current room determined from the database, you pass them off
to that room, just like normal (except that there is no room for
them to be leaving from).

Actually, since you said the distributer creates the processes for
newly active rooms, I would have it create the socket, too. Then the
new room process would simply open it, by name, to have its connection
to the distributer. Note that these AF_UNIX sockets are strictly local
to your one computer, and so their port numbers are an irrelevant
detail - no process ever needs to know what they are. Actually, with
named sockets this way, you don't need to bounce things through the
distributer, come to think of it! To pass a player from one process
to another, just have the old room open the local socket to the new room,
write the info (and client socket) down it, then close it again. The new
room knows that only transfer messages come over its local socket,
so it knows to handle it different than stuff coming over client sockets.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA