Jump to content

  • Log In with Google      Sign In   
  • Create Account


Multithread server design


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 NLScotty   Members   -  Reputation: 402

Like
0Likes
Like

Posted 15 June 2014 - 02:41 PM

Hello,

 

I'm currently writing a game server. I am using boost::asio with the io_service. I am walking into trouble with a session class going out of scope ( I am not sure when to deleted it safely) and sending packets to more than 1 client. This is my current code

class io_pool
{
	void Run(int threads)
	{
		// make as much threads as user wants + call io_service.run from all threads
		// so I have one io_service, which consumes more than 1 thrread
	}
}

// the server that accepts
class server
{
	void Accept()
	{
		// create new session and wait for session to connect
	}
	
	void OnAccept()
	{
		// call session start, and call accept again to wait for more
	}
}

// a connection from a client
class session
{
	// keep track of a client
	// holds SendPacket, RecvPacket and stuff like that
        // here is no problem with multithread since the callback frmo a socket can't be called at the same time
}

// the basic class
class client
{
	// holds info about character, map etcetc
	// has also a SendPacket() function which calls the session one.
}

// keeps track of all players in maps
class world_server
{
	std::map<dword /* map id*/, std::vector<std::shared_ptr<client>>>; // to hold info about the players in a map
	
	void AddPlayer(dword map id, client);
		void RemovePlayer(dword map id, client);

	std::vector<std::shared_ptr<client>>& GetPlayersdword (map_id);
}

In the Io_service pool, I create the one io_service that I pass around in the entire program.

 

The problem start when the user or I closes the socket. The read_async() function from boost calls the callback function with an error code like this:

void Session::Stop()
	{
		m_socket.shutdown(boost::asio::socket_base::shutdown_both);
		m_socket.close();

		m_time_out.Stop();

		// call here the delete function in tcp_server class?
	}

if (e || bytes_transferred != 4)
	{
			if (e == boost::asio::error::operation_aborted)
				return;
			
			Stop();
			return;
		}

But sometimes the error code is not operation_aborted when I call the socket.close/shutdown(). And this gives an error in my Stop() function, since I abort the same socket twice + when I call the delete function (which calls the server DeleteClient()) I get acces violation, cause the class is out of scope.

 

That also brings my next problem, what happens when another session, is updating movement from itself and wants to send the info to all other sessions in the same map. I call io_service.post(), with the client.SendPacket as info. But if session is deleted by then, this is not going to end well with the same errors as above.

 

What I came up with as ugly solution is to delete the session class after 30 seconds with a timer. Since I guess that none of handlers take 30 secs to be called, this should work. Though it looks ugly to me.

 

Thanks for reading, I apreciate any all cirtism about the design

 

Gr



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5164

Like
1Likes
Like

Posted 15 June 2014 - 06:36 PM

Put in print statements in the session constructors (main constructor, copy constructor) as well as the session destructor.
Then put in print statements in the code that causes the problems.
Check out the sequence of events.
If you think you need more information, then start with the debugger and put a breakpoint in the destructor, and see what's calling it.

Are you using boost::shared_ptr<> for the objects you pass in to the io_service? With boost::bind?
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS