Send Data on NetworkStream Getting Stuck

The IDE seems to get stuck on this one line of code in our SendData. I wanted to see what you recommend to fix or debug this. We have tried a few debug.print type things. We are just getting some serialization over the network setup and tested.

vb Code:

''' <summary>
    ''' Sends binary data.
    ''' </summary>
    Public Sub sendData(ByVal data() As Byte, Optional ByVal curStream As NetworkStream = Nothing)
        Try
            Dim endbytes() As Byte = System.Text.Encoding.ASCII.GetBytes("{682427e7-6a56-4513-87f1-2dec81ddae2d}")
 
            Dim lenBytes() As Byte = System.Text.Encoding.ASCII.GetBytes(data.Length)
 
            curStream.Write(lenBytes, 0, lenBytes.Length)  '<------- when paused, cursor goes here with Green arrow (it says it will continue here but it never does).
            curStream.Write(endbytes, 0, endbytes.Length) 
 
            curStream.Write(data, 0, data.Length)
            curStream.Flush()
 
        Catch
 
        End Try
 
        'If curStream IsNot Nothing Then
        '    curStream.Write(data, 0, data.Length)
        'End If
 
    End Sub

I tried a few changes like SyncLock and CanWrite but it is still having the same issue:

vb Code:

''' <summary>
    ''' Sends binary data.
    ''' </summary>
    Public Sub sendData(ByVal data() As Byte, Optional ByVal curStream As NetworkStream = Nothing)
 
        Try
            SyncLock curStream
                Dim endbytes() As Byte = System.Text.Encoding.ASCII.GetBytes("{682427e7-6a56-4513-87f1-2dec81ddae2d}")
 
                Dim lenBytes() As Byte = System.Text.Encoding.ASCII.GetBytes(data.Length)
 
                If curStream.CanWrite Then
                    curStream.Write(lenBytes, 0, lenBytes.Length)  '<----------- It is getting stuck here sometimes
                End If
                If curStream.CanWrite Then
                    curStream.Write(endbytes, 0, endbytes.Length)  '<----------- It is getting stuck here sometimes
                End If
                If curStream.CanWrite Then
                    curStream.Write(data, 0, data.Length)
                End If
                curStream.Flush()
            End SyncLock
        Catch
 
        End Try
 
        'If curStream IsNot Nothing Then
        '    curStream.Write(data, 0, data.Length)
        'End If
 
    End Sub

Synclock is unlikely to have any impact on this. If you are calling SendData from multiple threads, then locking may be reasonable, but I would be inclined to lock at a higher level (lock the whole method), and not use the stream as the lock object. Still, I doubt that is at all related to the issue. The issue, one way or another, is probably related to this line from the MSDN documentation:

Quote:

---

The Write method blocks until the requested number of bytes is sent or a SocketException is thrown

---

I suspect that if you pass in a length that is not less than or equal to the number of bytes, that would cause the problem you are seeing. The first thing I would do would be to take a look at the byte array and the length. Naturally, I would expect that since the length came from the byte array, it should be the same, but take a look. Also, it may be that there is a bad byte in that array. I'm not quite sure how Write works, but it may stop at a termination character, which could be nearly any value, but I would expect &H0. Therefore, the next test I would try would be to make up a dummy data array as an array of known byte values, and see whether that worked.

Hmm, I know this normally works, because we use the function/class for some other things in the game. Although, it is newly written so it still has some issues. I am getting the error this time on the 2nd line. Which is very interesting because the 'endbytes' string is a string set earlier in the same function. It has a green arrow and a blue dot on the left side and says: 'This is the next statement to execute when this thread returns from the current function.' Then if I hit play and pause again it comes back to the same spot with the same green arrow, but no blue dot. Also both times the data is the same:

endbytes = {Length=38}

The data contains 38 bytes from 45-125 representing this: "{682427e7-6a56-4513-87f1-2dec81ddae2d}"

Yeah, that's a bit odd. That appears to be a typical GUID, and the array shouldn't have any termination bytes by any means. The behavior certainly suggests that the Write method is blocking, but I'm not so sure why. How did you get it to get through the first line?

The issue seems random. Sometimes it locks on the first one (which is actually just a 3 string with the length of the data (usually around 450)).

Truly random would be kind of bad. One thing you might consider is adding something to log the arguments that are going to the method before the call. Something as simple as a pair of lists would do. The point would be to try to find a pattern in the random.

Aside from that, you might look at WriteTimeout. This would be the "Give Up" option, though, but it would give you another test, potentially: If you added a write timeout, then if the timeout occurred, you could re-write the same thing. If it is ALWAYS blocking for certain arguments (which the failure of the second line suggests is NOT the case), then you might be able to identify the arguments that cause the blockage. If it really is random, then a second try would cause the exact same arguments to go through, in which case you have to look elsewhere.

Have you tried sending something else? Something a bit simpler perhaps? could it be an issue with the receiving end of your curStream?

something else ... have you tried putting everything into one single byte array first, and then sending just that?

I'm just thinking out loud here... networking and sockets are not my bailywick, so it's possible I'm completely out of bounds here.

-tg

I am thinking that we may have overloaded the function with calls somehow. Anyways, the WriteTimeout seems very useful as well. I will let you know if we are still stuck. It may take another day or so for testing :)

Network issues are SUCH a joy.