I'm guessing you are writing a MUD server in perl here (given use MUD::Net..., if that's the wrong then the following may have no bearing on reality. :) The reason I'm guessing is because you haven't told us anything more than it's mult-user and a network oriented, which could cover many things, eg a web-server, a bulletin board, a irc server, a multi-player solitaire program....
No MUD engine I'm aware of forks, the reason is basically that the network interaction is not the difficult/expensive/interesting part of the program, rather the interaction between the entities is eg. Mobs moving/hunting, players chatting, the sky falling :) or another way of putting it, the main loop is timer driven rather than network driven. So, in order to use a forking model you have to either have all that interaction happening in *each* process AND synchronized between the processes or each forked process talking back to a central process which is probably going to be by something like sockets, at which point you've only increased complexity. Theoretically you could have each entity represented by a process and talking to a central process, which may make sense if designed well but that's probably overly complex. Not to mention that when you fork you make a complete copy of all memory which in a MUD could run near 100 Mb easily
Now that I've told you why I don't think it's a good idea to fork, heres the basic idea of how :) figure out what the network module needs to be able to do, in this case something like read, write, select, connect, disconnect, accept... it doesn't matter how they are implemented, all that matters is given the same arguments they give you the same end result. so accept for fork would be something like
$sock = $mother->accept();
create sharedmem/pipe/unixsocket;
if fork {return identifier($sock)}
else {pass_data_between_socket_and_main($sock)}
and the select version
$sock = $mother->accept();
push @socks, $sock;
return identifier($sock)
In short you've overreached my ability to come up with a decent reason/design/implementation of forking for a MUD :). However if you are doing something else, specifically something where you basically open connections that don't need to interact with eachother then a forking solution makes much more sense and none of what I've said here applies.
