Copyover and accept_new

Posted by Greven on Thu 13 Nov 2003 08:19 PM — 6 posts, 14,810 views.

Greven Canada Thu 13 Nov 2003 08:19 PM #0

Having a small problem, after I copyover, I am not able to have new connections made, they hang. I know the bit of code that is being affected. I used log strings inside of accept_new, and I've determined that

	if ( FD_ISSET( ctrl, &in_set ) )
	{    
	    newdesc = ctrl;
	    new_descriptor( newdesc );
	}

is the offending code, apparently it's true before a copyover, but not after. Does anyone know whats going on with that if check? Whats it checking for? I THINK thats its seeing if a route for incoming data from the new descriptor has been established, and it is before a copyovr, but not after. I went and read the back posts, and this exact problem has occured before. Now, problem seems to be because I am running two different ports, my main and my coding. After I copyover, the value for control is the same on both ports, and if I understand correctly, that should be what the problem is. Should you not be able to re-assign the control based on the passed port? Why do you not want to call init_socket after a copyover?

Greven Canada Thu 13 Nov 2003 09:06 PM #1

Well, I did actually find a solution to it, but I'd still like to know why you can't call init_socket after a copyover, or why my two muds would be able to run on the same control socket.

David Haley USA Thu 13 Nov 2003 10:07 PM #2

A control socket is also called a "listener" socket. It's a special file descriptor that is "ready for reading" when someone is initiating a connection request. new_descriptor(ctrl) is accepting a new connecting from the descriptor ctrl - in fact the "accept" function should be called inside that function.

Two MUDs cannot run on the same port because the second one will not be able to open up the port, because it's already in use. However, if two MUDs are using the same DESCRIPTOR (similar but not the same as which port you are listening to) then behavior is undefined since both processes could be reading from the same listener socket... that's not good.

I don't know what init_socket shouldn't be called after a copyover. I don't have that code in front of me and don't remember what it does.
The way copyover works is that it does not actually close descriptors, it leaves them open and stores them in a file. The new process reads these descriptor numbers and simply recreates connections that use those file descriptors.

It's actually quite a complex subject, and you'd need some background in networking to really see what's going on.

The line if (FD_ISSET...) is checking if the descriptor "ctrl" is in the set of descriptors ready for input (reading), as determined by the select call which occurs at the beginning of game_loop as I remember.

Samson USA Fri 14 Nov 2003 12:22 AM #3

To put it simply, you don't want to call init_socket after a copyover because the socket is already open. It carried over when you ran the copyover command. That's the whole point of it. And you really shouldn't be able to make both muds listen to the same port. If you did, something is really REALLY screwed up in your configuration.

Greven Canada Sat 15 Nov 2003 06:09 AM #4

Yeah, seems to me that my code is kinda screwy, but besides small things like this, I don't seem to be having to much trouble. Yet still, I have one running on port 4848 and another on 4872, but after a copyover, both have "5" passed on as the control, but I don't seem to have troubles with that. Thank for the help with this.

David Haley USA Sat 15 Nov 2003 06:37 AM #5

I'm rather surprised that both versions get the same file descriptor (control number if you will), and I'm even more surprised that it works after that! If I didn't have 700 thousand other things to do, I'd really want to look in to that to see how the heck it works. As Samson said that's really not something you'd want to have. :)