Hi, 

I am having a problem reading data from a network. Here is the code of the thread that listening from a thread and saving the content as string. 

private void ReadData()
    {
        string lMessageInString;

        print("Reading data");


        byte[] lInStream = new byte[1024];
        char[] lCharStream = new char[1024];

        serverStream = clientSocket.GetStream();

        while (true)
        {
            print("While True");

            serverStream.Read(lInStream, 0, lInStream.Length);

            for (int i = 0; i < lInStream.Length; i++)
            {
                lCharStream[i] = (char)(((int)lInStream[i]));
            }

            lMessageInString = new string(lCharStream);

            print("The message length: " + lMessageInString.Length);

            ProcessMessage(lMessageInString);

            print(lMessageInString);
        }

    }

The code seems to work but I have a problem trying to optimize the code. THe size of the string (which is derived from the array of char) is 1024 instead of the size of the character sent by the network. Using method serverStream.Length seems to fail the program. How can I limit the string length to match the size of the received characters from the stream? ie. if there are only 10 characters (bytes), the string will have 10 characters instead of the maximum 1024. It seems redundant to process the whole array when the stream only sent 10 characters. 

Thank you in advance

All Stream.Read calls (even non-TCP ones) should be written so that they are capable of handling the case where the return value is less than the desired number of bytes.  You should assume that this type of thing can happen on any Stream type.

See the example on Stream.Read for one way to write a loop like this:

https://docs.microsoft.com/en-us/dotnet/api/system.io.stream.read?view=netframework-4.7.2

14 hours ago, jt.tarigan said:

Using method serverStream.Length seems to fail the program.

You should be seeing an exception for this, "fail the program" is not generally useful for debugging. Are you catching the exceptions? Are you running this code in Visual Studio or some other IDE? If the exception is not caught it should give you a popup, otherwise I generally find it useful to go to the "Exceptions" window and have it break on all exceptions to help catch issues sooner with as much stack context as possible.

In this case, from the documentation for NetworkStream you should see it is not seekable and you should be seeing a "NotSupportedException". https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.networkstream?view=netframework-4.7.2

Quote

The NetworkStream does not support random access to the network data stream. The value of the CanSeek property, which indicates whether the stream supports seeking, is always false; reading the Position property, reading the Length property, or calling the Seek method will throw a NotSupportedException.

Thanks for the replies. I think I have a rough idea of how to solve this problem. In short, there is no way to know the length of the byte stream received. What I can do is to modify my protocol so the first thing I put in the data is the length of the data. When the message is received, I should check the length first before going through the data. Is that correct?

I'm using Unity + Visual Studio. I am debugging with Unity's built-in console, it does not help very much in showing errors. Sometimes, it just stopped without showing anything. 

8 hours ago, jt.tarigan said:

I'm using Unity + Visual Studio. I am debugging with Unity's built-in console, it does not help very much in showing errors. Sometimes, it just stopped without showing anything. 

Debugging in Visual Studio proper should be possible. Breakpoints, variable inspection, single step, etc.

Apparently Unity made a change so you don't get unhandled exceptions, but catching them on throw or any other sort of breakpoint should work.

Quote

https://developercommunity.visualstudio.com/content/problem/230762/unity-debugger-didnt-break-on-exception-with-net-4.html

With the new runtime (.NET 4.6 equivalent), Unity introduced a new way for managing user exceptions and as a result, all exceptions are seen as "user-handled" even if they are outside a try/catch block. That's why you now need to explicitly check them in the Exception Settings Window if you want the debugger to break.

10 hours ago, jt.tarigan said:

 I think I have a rough idea of how to solve this problem. In short, there is no way to know the length of the byte stream received.

No, there is of course, it is the return value of Read() fuction, that you're not using up.

2 hours ago, JohnnyCode said:

No, there is of course, it is the return value of Read() fuction, that you're not using up.

The return value is an important part, but you can't use it to directly determine TCP "message size". It could be part of the message or maybe you read part of two messages. Even in a directly single command-response scheme with no pipe-lining, with that alone you don't know if a message is "complete" or not without some long timeout or dropping the connection (as original HTTP did for responses of unknown length), and then actual connection drops can mess with it (incomplete download, no way to tell).