• Create Account

### #ActualTheis_Bane

Posted 21 February 2013 - 07:15 PM

First, thanks for the swift reply.  It's given me quite a bit to think about.

Second, I've chosen to prefix my messages with  and suffix them with ~~ because these are the separators I use in the command strings I pass between client and server.  On the client side, I've disabled that key on the keyboard and include checks to make sure they haven't copy/pasted those keys into the command line.  So that shouldn't be a problem.

Third, the buffer size for the server need not be very large, as the clients pass very little information up to the server, mostly just a parsed sentence indicating their chosen action.  And, correct me if I'm wrong, as I could have any number of clients connected at once, keeping the server's buffer size small will keep the RAM usage down.  As for the client side, I agree that it would be a good idea to increase the buffer size.  Since the client program isn't very big anyway, this won't really hurt it.

Fourth, you say ASCII encoding is bad, but you didn't point me toward a better alternative.  Thoughts?

Last, my updated buffer handling!  Only took me about 20 minutes to fix it.

private void ReceiveMessage(IAsyncResult Result)
{
ClientInfo thisClient = (ClientInfo)Result.AsyncState;

try
{

//If we've received any sort of message...
{
//Translate the message and determine begin points and end points
string Contents = Encoding.ASCII.GetString(thisClient.Buffer, 0, AmountReceived);
thisClient.Buffer = new byte[BUFFER_SIZE];

int TermLoc = 0;

while (true)
{
TermLoc = Contents.IndexOf(FOOTER);

//If we have a begin point...
{
//...and an end point, and begin comes first...
if (TermLoc > -1 & HeadLoc < TermLoc)
{
Received = Contents.Substring(0, TermLoc + 2);
Contents = Contents.Remove(0, TermLoc + 2);
}
//...and an end point, but end comes first...
else if (TermLoc > -1 & TermLoc < HeadLoc)
{
Received = thisClient.RecIncom + Contents.Substring(0, TermLoc + 2);
Contents = Contents.Remove(0, TermLoc + 2);
}
//...but no end point...
else
{
//This is a partial message.  Load into ReceivedIncomplete and break the loop to refill the buffer.
thisClient.RecIncom = Contents;
break;
}
}
//If we DON'T have a begin point...
else
{
//...but we DO have an end point
if (TermLoc > -1)
{
//This is the rest of a partial message, so we just add the two together!
Received = thisClient.RecIncom + Contents.Substring(0, TermLoc + 1);
Contents = Contents.Substring(0, TermLoc + 1);
}
//...and we don't have an end point
else
{
//This is more of a partial message, so just add it and start receiving again
thisClient.RecIncom += Contents;
break;
}
}

//If a complete message was received, parse it out into RequestModel object and add it to the game loop
{
string[] AccountSplit = Split[0].Split('~');
string[] MessageSplit = Split[1].Split('~');

//Message received format = AccountID~CharacterIDect~ect.
RequestModel Request = new RequestModel();
Request.Client = thisClient.WorkSocket;
Request.AccountName = AccountSplit[0];
Request.CharacterID = AccountSplit[1];
Request.Request = MessageSplit;
}

}

}
}
catch
{
}
}


Thanks again!

### #1Theis_Bane

Posted 21 February 2013 - 06:44 PM

First, thanks for the swift reply.  It's given me quite a bit to think about.

Second, I've chosen to prefix my messages with  and suffix them with ~~ because these are the separators I use in the command strings I pass between client and server.  On the client side, I've disabled that key on the keyboard and include checks to make sure they haven't copy/pasted those keys into the command line.  So that shouldn't be a problem.

Third, the buffer size for the server need not be very large, as the clients pass very little information up to the server, mostly just a parsed sentence indicating their chosen action.  And, correct me if I'm wrong, as I could have any number of clients connected at once, keeping the server's buffer size small will keep the RAM usage down.  As for the client side, I agree that it would be a good idea to increase the buffer size.  Since the client program isn't very big anyway, this won't really hurt it.

Fourth, you say ASCII encoding is bad, but you didn't point me toward a better alternative.  Thoughts?

Last, I'm working on shortening up my buffer handling, and will post the results to that (hopefully) soon.

Thanks again!

PARTNERS