TCP Server NetworkModel for MUD

Started by
16 comments, last by hplus0603 11 years, 1 month ago

Yup, the messages never overlap each other, but they can overlap the 'edge' of individual receive calls.

Advertisement
Think of it this way: Reading from a TCP stream is like reading from a file where you cannot seek.
How would you read your message data from a file? You'd have to know how much to read before you read it. So, make it so!
enum Bool { True, False, FileNotFound };

Haven't forgot about this. Real life and computer problems and all that. Will update my program soon and post changes, hopefully this weekend.

EDIT Ran into a few problems...Reworking now...
You don't need 2 separate and different calls to Client.WorkSocket.BeginReceive. One of the existing calls has a logic error, currently. Consider some edge cases to work out which one it is, and consider consolidating that logic into one call. Apart from that, it appears that it will do the right thing.

Yeah, I just found my logic error. Reworking it as we speak.

Okay, changed it up. Wow. Lot shorter.


private void GetMessage(ClientInfo Client)
        {
            int TermLoc = 0;            
           
            TermLoc = Array.IndexOf(Client.Buffer, FOOTERVAL);                  
            
            if (TermLoc > -1)
            {
                //Translate buffer, parse message and send it to game loop
                PassMessage(Client, e.GetString(Client.Buffer, 0, TermLoc));

                //Remove received message and look for more
                Client.AmountHeld -= TermLoc + 1;
                Array.Copy(Client.Buffer, TermLoc + 1, Client.Buffer, 0, Client.AmountHeld);
            }
            Client.WorkSocket.BeginReceive(Client.Buffer, Client.AmountHeld, BUFFER_SIZE - Client.AmountHeld, SocketFlags.None,
                   new AsyncCallback(ReceiveMessage), Client);           
        }

I was trying to work WAY too hard before. I think this pretty much solves all my problems.

I'm wondering why message overlap is even a problem in a TCP stream? The data is always in order and guaranteed.

That's right! TCP is very much like a file -- data is in order, and guaranteed. It's like a file that you can't seek backwards or forwards in, just read bytes from.
If you were to read a sequence of commands from a file, how would you know how many bytes to read for each command? Reading from a TCP stream is very similar to that.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement