My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

C

Clive

Hello everyone,

This is my first time posting, up until now i've only used google to seach
:)

I'm creating a multiplayer minesweeper game in Windows, so I have been
reading up on CSockets. I am begining to have a grasp on them, but I have
this one query.

If a socket some data comes along that isnt part of my protocol, I want to
remove the close the socket and delete it. The main question is on a
OnReceive call can you tell the socket to delete itself?

The CSockets have OnReceive functions, my understanding of them is that
you implement them yourself and they then get called when any data is
sitting
on the Socket (i like this far better than an infinitely better idea than
blocking
my game's process :).

If this does get called from Windows, then it is not apart of my game's
process, it runs parallel with it but does have access to all the functions.
I
haven't actually tested if this is true yet. If someone can verify that my
understanding of how the OnReceive function works, that would be great.

So it's like this
// Multi-mine protocol CSocket
MMPCSocket::OnReceive(int nErrorCode){
Network::MMP msg; //enum for all the allowable protocol numbers.
int bytes = Receive(&msg, sizeof(n->MMP));

if(bytes == sizeof(n->MMP){ // read the correct number of bytes
network->processPendingMessage(msg);
}
else{
msg = network->mmp_server_received_bad_packet; //part of
MMP
Send(&msg, sizeof(n->MMP));
network->deleteSocket(player);
/* player is the reference to this socket */
}
}

Network::deleteSocket(int player){
delete myConnections[player];
myConnections[player] = NULL;
/* my current idea is that if a socket is null, means it can be reused
for a new player */
}

Does that cause problems from the perspective of the game?
I could imagine that there is a small possibility that just at this
moment when I'm trying to delete it... my actual game is trying to send
a message to it.

Like within my game, it's going

For(all my players)
If(myConnections[player] != NULL){
/* meanwhile, the deleteSocket has been run and
it's gone and deleted the socket */
int answer = myConnections[player].Send(some data, some
number);
}

I don't see this as really being a problem.. because if the socket has
been deleted, the Send message will return a WSANOTINITIALISED error to
the GetLastError function. Whether I check or care about that is up to
how I create my program, hopefully it wouldn't be necessary and the
Network layer would have taken care of all that i.e. told all players
that player x is gone now).

The same goes if later on in the processPendingMessage part.. it finds
out that the message is actually bogus.. it would also call the
deleteSocket(player).

Is this a smart way to go about things? An alternative to this would be just
to
Close the CSocket from within the OnReceive function.. then later on.. in my
game process, every second or so.. check if any CSockets are closed, and
delete them as required...

Thanks for reading all the way to the end :)
 
A

Aggro

Clive said:
Hello everyone,

This is my first time posting, up until now i've only used google to seach
:)

I'm creating a multiplayer minesweeper game in Windows, so I have been
reading up on CSockets. I am begining to have a grasp on them, but I have
this one query.

If a socket some data comes along that isnt part of my protocol, I want to
remove the close the socket and delete it. The main question is on a
OnReceive call can you tell the socket to delete itself?

CSocket is not part of the standard C++. This group is for standard C++
questions only.

Perhaps you could find help from:

microsoft.public.vc.mfc
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top