Sign in to follow this  

[C#] Sent & Received data

This topic is 3555 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I ran into some trouble checking the received data (Server <-> Client) for my ORPG. For example when the client presses the right arrow, it sends a packet containing a "r" value to the server, and the server is supposed to approve it by sending it back, therefore allowing the player on the client to actually move. The problem is in the client when I receive the packet data and convert it into a string, I then check 'if(data == "r") { moveRight(); }' (etc. for all directions). The client always seems to return 'false' when it checks if data == "r", when data indeed IS == "r". I used Console.WriteLine(data) to check its value and it indeed is "r", I'm really confused. Client receive data and checking code -------------------------------------
    public void onDataReceive(IAsyncResult result)
    {
        try
        {
            Packet socketPacket = (Packet)result.AsyncState;
            int dataSize = 0;
            dataSize = socketPacket.socket.EndReceive(result);
            char[] chars = new char[dataSize + 1];
            System.Text.Decoder decoder = System.Text.Encoding.UTF8.GetDecoder();
            int charLen = decoder.GetChars(socketPacket.buffer, 0, dataSize, chars, 0);
            string fData = new string(chars);

            System.Console.WriteLine(fData); // this outputs r

            if(fData == "r")
                  mainPlayer.moveRight(); // this never happens even though fData IS EQUAL TO "r"!!!!!!!!!!

            waitForData(playerSocket);
        }
        catch (SocketException se)
        {
            MessageBox.Show("Lost connection to server.");
        }
    }

Share this post


Link to post
Share on other sites
Quote:
new char[dataSize + 1]

Your cvec will have a null on the back. You need to test for "r\0". Also, I hope this is UDP because in TCP the packets get run together and messages get conflated.

Share this post


Link to post
Share on other sites

This topic is 3555 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this