As I approach doing server stuff again, my worry alarms go off...
What happens if I have a server.dmb and multiple hubbed games connect at once? I know that for webserver stuff, each gets its own copy, but I assume that's not the case for regular .dmbs.
I believe it's been said that a savefile can only be opened for writing by one process...what happens in this scenario:
I have a screenshot.dmb on the server to handle screenshot functionality for all the hubbed instances of the game.
Two instances of the game try to hook up at once.
Each sends a screenshot (which is large and takes a while to upload) to the server.
The server writes the screenshot to disk as a normal file and adds data for the screenshot to a savefile.
Is there some case where one of the games attempting to connect is going to fail? If so, is there a way for me to know it failed? Is there a case where writing to the savefile is going to fail?
ID:154588
 Dec 22 2000, 1:22 pm
|
|
On 12/22/00 5:45 pm Tom H. wrote:
On 12/22/00 4:22 pm Deadron wrote: Great -- sounds like everything should work. I'll probably start with the screenshot functionality integrated, until I have everything tweaked the way I want, then split it into a server. | |
You should only have one instance of your server.dmb file running. Since DMBs are single-threaded, you will then be protected from any savefile or rsc conflicts. Two files that get uploaded "simultaneously" will be buffered such that they will both get stored in the .rsc file without overwriting one another. And when you copy the .rsc data to your savefile, that will work too since the savefile operations are done sequentially (due to the single-thread).
If you do happen to have the same server.dmb file running multiple times in the same directory, you will run into problems. The first problem is that the .rsc file is "locked", so you'll only be able to write to a copy of it. And your intuition is correct in saying that the savefiles will not work properly. You will get a DEBUG statement to this effect, and I believe the savefile var should return as null when you do new/savefile for the second server.
I just did a bit of testing and ran into some other unexpected glitches when dealing with this situation. So I wouldn't advise it. I believe the hub will protect against this case, but Dan will be able to give you a much better description.