简体   繁体   中英

NetworkStream read skipping packets

I am trying to implement a TCPClient using the async BeginRead to listen to a custom application. The listening code is this:

    ClientState cs;

    void Update()
    {
        lock (lockObj)
        {
            if (cs != null)
            {
                if (cs.bytesReceived > 0)
                {
                    ReceiveNetworkMsg?.Invoke(cs.receiveBuffer, cs.bytesReceived);
                    Array.Clear(cs.receiveBuffer, 0, cs.bytesReceived);
                    cs.bytesReceived = 0;
                }
            }
        }
    }

    IEnumerator ListenForData()
    {
        Debug.Log("Listening");

        stream = client.GetStream();
        cs = new ClientState(stream);

        do
        {
            //stream.BeginRead(buffer, 0, buffer.Length, MessageReceived, client);
            stream.BeginRead(cs.buffer, 0, cs.buffer.Length, new AsyncCallback(ReadCallback), cs);
            yield return null;
        } while (client != null);
    }

    void ReadCallback(IAsyncResult result)
    {
        ClientState cs = (ClientState)result.AsyncState;

        lock (lockObj)
        {
            int currBytesReceived = cs.stream.EndRead(result);
            Array.Copy(cs.buffer, 0, cs.receiveBuffer, cs.bytesReceived, currBytesReceived);
            Debug.Log("Network receiving: " + currBytesReceived + " " + cs.bytesReceived + " bytes. " + BitConverter.ToString(cs.buffer, 0, currBytesReceived));
            cs.bytesReceived += currBytesReceived;
        }
    }

At a certain point when the server sends a series of messages, the bytes received does not match the actual bytes sent:

Wireshark log:

No.     Time           Source                Destination           Protocol Length Info
     35 0.619977       127.0.0.1             127.0.0.1             TCP      64     5001 → 49872 [PSH, ACK] Seq=53 Ack=140 Win=28 Len=20

0000  14 00 23 11 4a 3e 01 01 1c 10 02 00 00 00 00 00   ..#.J>..........
0010  02 01 22 00                                       ..".
    Data: 140023114a3e01011c1002000000000002012200
    [Length: 20]

No.     Time           Source                Destination           Protocol Length Info
     39 0.621735       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=73 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     43 0.623598       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=94 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     47 0.625630       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=115 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     51 0.627592       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=136 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     55 0.629683       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=157 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     59 0.632344       127.0.0.1             127.0.0.1             TCP      65     5001 → 49872 [PSH, ACK] Seq=178 Ack=140 Win=28 Len=21

0000  15 00 99 b2 b6 07 01 01 06 10 02 00 00 00 00 00   ................
0010  00 00 00 00 00                                    .....
    Data: 150099b2b607010106100200000000000000000000
    [Length: 21]

No.     Time           Source                Destination           Protocol Length Info
     65 0.634544       127.0.0.1             127.0.0.1             TCP      62     5001 → 49872 [PSH, ACK] Seq=199 Ack=166 Win=28 Len=18

0000  12 00 57 c1 55 6c 01 01 03 10 02 01 00 00 00 00   ..W.Ul..........
0010  00 02                                             ..
    Data: 120057c1556c010103100201000000000002
    [Length: 18]

Logs:

Network receiving: 20 0 bytes. 14-00-9D-59-A2-54-01-01-1C-10-02-00-00-00-00-00-02-01-1F-00

Network receiving: 21 20 bytes. 15-00-99-B2-B6-07-01-01-06-10-02-00-00-00-00-00-00-00-00-00-00

Network receiving: 21 41 bytes. 15-00-99-B2-B6-07-01-01-06-10-02-00-00-00-00-00-00-00-00-00-00

Network receiving: 21 62 bytes. 15-00-99-B2-B6-07-01-01-06-10-02-00-00-00-00-00-00-00-00-00-00

Network receiving: 21 83 bytes. 15-00-99-B2-B6-07-01-01-06-10-02-00-00-00-00-00-00-00-00-00-00

Network receiving: 21 104 bytes. 15-00-99-B2-B6-07-01-01-06-10-02-00-00-00-00-00-00-00-00-00-00

Network receiving: 21 0 bytes. 12-00-57-C1-55-6C-01-01-03-10-02-01-00-00-00-00-00-02-00-00-00

Network receiving: 18 21 bytes. 12-00-57-C1-55-6C-01-01-03-10-02-01-00-00-00-00-00-02

After the 20 byte message, there are supposed to be 6 21 byte messages before the 18 byte one. My receive side first processes the first 5 21 byte message, then for some reason when it is trying to process the 6th 21 byte message it is returning the correct size but it is getting the 18 byte message.

Am I missing out on something fundamental here?

the network stream received 21 bytes 6 times; what ClientState did with them between the 104 and the 0 - is up to ClientState , which: we can't see. It sounds like a competing thread made ClientState consume the buffer. Note, however, that IMO your expectations are incorrect here; I fundamentally disagree with the statement:

there are supposed to be 6 21 byte messages before the 18 byte one

The code we're looking at is TCP, which deals in streams, not messages; there is no guarantee that it will arrive in 6 21-byte pieces. It could all arrive in a single 126-byte chunk, or it could arrive in 126 separate 1-byte pieces. All you are guaranteed is: the same bytes in the same order (or a failure, perhaps, if a broken socket is detected).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM