Tcp Sockets

[campster]

I'm connecting to a remote PC via a TCP socket. I can connect fine but I only seem to get one chunck of data.

I thought that the code below would continuously request data from the remote PC and, for now, dump the data to a message box. This works the first time through, kind of.

Here's what happens: I'm asking for 1000 bytes of data (The remote PC sends more that 1000 bytes). I get this data and it is displayed properly. I thought that my second request for data would overwrite the existing buffer, instead what I get is the second 1000 bytes of the first request. This happens until the original buffer is empty then my message box appears with no text (only the OK button os visible).

Can any one see what I'm missing? This is my first attempt at sockets so most of my code is cut and paste. Still trying to decipher what it all means.

'Not really using this IP Address
    Private pierAddress as String = "127.0.0.1"
    Private telnetPort as Integer = 23
    Private tcp as New TcpClient
 
    Private SubRefreshPlotData
        Dim Done as Boolean = False
 
        Do While Not Done
            getKrData()
            Thread.CurrentThread.Sleep(500)
        Loop
    End Sub
 
    Private Sub getKrData()
        Dim address As IPAddress = IPAddress.Parse(pierAddress)
        Dim ipEndPoint As New IPEndPoint(address, telnetPort)
        Dim data As Byte()
        Dim responseData As String = String.Empty
 
        data = New Byte(999) {}
 
        Try
            tcp.Connect(ipEndPoint)
            Dim stream As NetworkStream = tcp.GetStream()
            Dim bytes As Int32 = stream.Read(data, 0, data.Length)
            responseData = System.Text.Encoding.ASCII.GetString(data, 0, bytes)
        Catch e As Exception
            Console.WriteLine(e.ToString())
        End Try
 
        MessageBox.Show(responseData)
 
        tcp.Close()
    End Sub

[Mike Hildner]

It's behaving just like it should. When you grab some data via stream.Read, the third arg is the number of bytes to read. Since you're passing the length of the array you're filling, you're telling it to give you 1000 bytes (or maybe 999 - 0 or 1 based array?).

Although the second read will overwrite the array of bytes you're passing in, it still just grabs whatever bytes it can from the input stream. Since you didn't exhaust all of the bytes the server sent the first time around, you're grabbing what's next.

Hope that makes sense.

Mike

[campster]

That makes sense but why does it not try and get a new input stream? Let's say that the data in the stream is 2500 bytes. I should get two sets of 1000 bytes and one set of 500 bytes but after that why does it not stream in a new set of data? I'm sure that it is doing exactly what I'm telling it do but I would rather it do what I want it to do.

[Mike Hildner]

Oh, I think I see what you mean now. In that example, is the other end sending more than the initial 2500 bytes?

I've never written code quite like that, so I'm not sure what's going on. In fact I'm suprised you get anything more than the initial 1000 bytes. Normally a socket would stay open for the length of the conversation, if not longer, but you're connecting and closing the socket with every iteration. I would have guessed that closing and reopening would discard anything that's left over.

Just to make sure I understand - you're getting 2500 bytes over three iterations but after that you don't get anything?

Mike

[campster]

Just to make sure I understand - you're getting 2500 bytes over three iterations but after that you don't get anything?

That's what appears to be happening. I just spoke to a coworker that thinks that the remote PC is set up to send a chunk of data when requsted and then it closes the connection. Then the whole hand shake has to happen again to get more data. Maybe should be doing this

Private tcp as New TcpClient

in the loop as well.

[Mike Hildner]

Ok, I don't use the TcpClient class, just the Socket. Was reading a little on MSDN and when you call .Close on TcpClient, it does not close the underlying network stream. That makes sense now. You need to manually close the stream if that's what you want it to do.

Since the stream is still open, it makes sense that you receive the rest of the input.

If your coworker is correct, I'd guess the fourth time around (in our ongoing example), you're blocking on tcp.Connect? It should either connect ok or throw an exception.

Mike

[campster]

Thanks for the help. I'll give it a shot tomorrow at work.

[campster]

Ok, I don't use the TcpClient class, just the Socket.

Is there any advantage/disadvantage of using one over the other?

[Mike Hildner]

It depends on the need of your application. TcpClient provides a simple way to do socket communications, but everything it does is synchronous -blocking.

Using the Socket, there's more work for the coder to do, but you have a lot more flexibility. I like to take advantage of the asynchronous (non-blocking) methods.

Mike