i've always wondered this and want to know if anyone has any insight on this:
how does smaug seemingly multi task? for example,
as an imm i will type prac and hit enter getting a list of all the spells/skills in game. isnt the program occupied with this process? how is it that i can toggle over to other char and be able to interact with mud while the other player is still recieving info for skill/spells?
shouldnt the program itself be occupied in do_practice and therefore not be able to answer requests recieved?
i hope my question makes sense.
all i can think of is there is something sperate in the tcp/ip protocols that acts as a buffer that is independent from smaug.exe and it's processes?
You mean, while the input is still scrolling along? The server buffers it, so it can gradually be sent while it is doing other things.
It is part of the main tcp/ip loop, that it pulls in packets (which might be part of a command) and waits for a linefeed until it does anything, and also sees if there is outstanding stuff to be sent.
game_loop:
1) check for new connection (descriptor)
2) loop through descriptors
a) check for idleness
b) check for command pause
c) no pause, read all input from descriptor, interpret next command in line
3) update entire mud via update_handler
4) loop through descriptors again now that we've kicked off everyone who shouldn't be on
a) print 512 bytes of current waiting output to the descriptor, the 512 is dependent on
if you use the client speed snippet or not, i use it, and it works awesome if ya haven't
tried it i suggest lookin at it
5) game stuff, syncronize to a clock, check descriptor links, etc
6) repeat
so yes any function takes complete priority, as that is how computers work per thread (from what i remember muds are all single threaded), however the output from any function in the game does not instantly send the data to the player, which is how you get your screen still scrolling and able to interact on a seperate character.
Well, there's also the fact that the game is simply fast enough to allow this kind of seeming interaction. Don't forget that a single-processor machine is doing massive amounts of multi-tasking, and yet all programs seem to be running simultaneously. Having several programs running at once is really just an illusion of sorts.
Basically the key in SMAUG is what Nick said; the operating system handles receiving and sending TCP/IP packets, so once SMAUG writes them out it doesn't have to worry about them anymore. That is how the SMAUG code is able to appear fluid -- it doesn't have to wait for a packet to be sent before being able to move on.
But, as you type 'prac', the entire MUD does indeed pause while the MUD puts the results of that command into your buffer, and tells the operating system to send it over the network. It's just that that process is so fast that nobody really notices it. You'd need a fairly slow machine (i.e. from probably more than 10 years ago) for things to start being really noticeably slow.
That being said, the SMAUG way of handling networking is not ideal. There have been several discussions of that on these forums, if you are interested in that.