Socket connected but send doesn't seem to work

[flyingpan]

I have an old vb6 desktop application which communicates with a mainframe server using socket (winsock 2) that i need to convert to .net. I found the small code which seems correct to me using System.Net.Socket. When running the console window just hang there showing blank.

        Dim s As Socket = ConnectSocket(server, port)

        If s Is Nothing Then
            Return "Connection failed"
        End If
        ' Send request to the server.

        Dim numSent As Integer
        numSent = s.Send(bytesSent)


        Dim bytes As Int32

        Do
            bytes = s.Receive(bytesReceived, bytesReceived.Length, 0)
            Console.WriteLine(bytes.ToString())

        Loop While bytes > 0

Here is the connect function

Private Function ConnectSocket(server As String, port As Integer) As Socket
        Dim s As Socket = Nothing
        Dim hostEntry As IPHostEntry = Nothing

        ' Get host related information.
        hostEntry = Dns.GetHostEntry(server)

        ' Loop through the AddressList to obtain the supported AddressFamily. This is to avoid
        ' an exception that occurs when the host host IP Address is not compatible with the address family
        ' (typical in the IPv6 case).
        Dim address As IPAddress

        For Each address In hostEntry.AddressList
            Dim endPoint As New IPEndPoint(address, port)
            Dim tempSocket As New Socket(endPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp)

            tempSocket.Connect(endPoint)

            If tempSocket.Connected Then
                s = tempSocket
                Exit For
            End If

        Next address

        Return s
    End Function

So I run wireshark on the port the app is communicating (port in the code above) I can see package sent and received with connectSocket, but no package is detected with s.Send(bytesSent). I wonder why.

[Peter Swinkels]

Hello, it is hard for me tell what exactly your question is. Do you mean you can't detect certain packages with WireShark or is this dection issue with your vb.net program?

[passel]

Did you step through the program to see what happens? If you've used vb6 in the past, hopefully you're familiar with stepping through code in the IDE to see where things go awry.

Also, the example you followed may not have been the best.
I think the receive call will block until you receive data, so bytes will never equal 0, so you will never leave the loop.
You may receive data back, tell it to write to the console, which will probably happen when the program has time to "breath", and immediately loop back and sit on the receive forever, and what you wrote to the console is never seen because you've hung the thread waiting on the receive.

[flyingpan]

Yes, I did step through the program, no exception or error was thrown. I got numSent =5, which is the number of characters i "Send". But no wireshark package is detected to leave my machine. Yes, it does hang on the do loop since nothing was received, which would consider normal if no packet was sent at the first place.

[flyingpan]

Hello, it is hard for me tell what exactly your question is. Do you mean you can't detect certain packages with WireShark or is this dection issue with your vb.net program?

I wasn't able to receive any package from the remote port. So I started wireshark to see what was the issue. I can't detect any packages sent from my machine to the remote port with s.Send(bytesSent), I DID get handshake packages in wireshark from my machine to remote port with ConnectSocket(server, port). I also stepped through the code and added try catch blocks, no exception or error was thrown. program runs normally till hang at do loop, which makes sense because no package was received.

My question is, is there obvious reason my package was not "sent", at least no package was detected to leave my machine. No firewall or antivirus present.

[passel]

Perhaps since you're using TCP, the Nagle algorithm is buffering the stream for efficiency, and your message is too short so is stuck in the buffer waiting for more byte stream before sending.
After your creation of tempSocket, you can try adding

tempSocket.NoDelay = True

to disable Nagle, and the data should be transmitted without consolidating multiple send calls into one transmission.

Haven't tested it. I've only used TcpClient class (System.Net.Sockets.TcpClient), and haven't experience any issues with data not being sent with that. I'm just guessing since you say you don't see the data going out, that Nagle may be a possible reason.

I already had a program that would wait for a TCP connetion, and read bytes from the stream, initially 4 bytes to get the size of the data coming and then it would read the data. The waiting for connection, then reading data ran in a background thread for simplicity.

I just tried a quick test of sending four bytes over a TCP connection to that application, from a console application using your code as an example, and I received the four bytes. I didn't need to set NoDelay, so I couldn't verify there was a problem, and that setting NoDelay would get around it.

Imports System.Net.Sockets
Imports System.Net

Module Module1

  Sub Main()
    Dim status As String = testSocket()
    Console.WriteLine(status)
    Console.ReadKey()
  End Sub

  Private Function testSocket() As String
    Dim s As Socket = ConnectSocket("127.0.0.1", 3030)
    Dim bytesSent() As Byte = {49, 50, 51, 52}

    If s Is Nothing Then
      Return "Connection failed"
    End If
    ' Send request to the server.

    Dim numSent As Integer
    numSent = s.Send(bytesSent)
    Return ("Bytes Sent")

  End Function

  Private Function ConnectSocket(server As String, port As Integer) As Socket
    Dim s As Socket = Nothing
    Dim hostEntry As IPHostEntry = Nothing

    ' Get host related information.
    '  hostEntry = Dns.GetHostEntry(server)

    ' Loop through the AddressList to obtain the supported AddressFamily. This is to avoid
    ' an exception that occurs when the host host IP Address is not compatible with the address family
    ' (typical in the IPv6 case).
    '  Dim address As IPAddress

    '   For Each address In hostEntry.AddressList
    Dim endPoint As New IPEndPoint(IPAddress.Parse(server), port)
    Dim tempSocket As New Socket(endPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp)

    tempSocket.Connect(endPoint)

    If tempSocket.Connected Then
      s = tempSocket
      '     Exit For
    End If

    '    Next address

    Return s
  End Function

End Module

Perhaps because I was using the local loopback IP address, Nagle doesn't get used because the data wouldn't actually go out the NIC, so Network efficiency doesn't really apply. The test could be invalid. But, I don't feel like setting up another computer on the network to do more testing, as I should be heading to bed anyway.

[flyingpan]

Thank you for mentioning Nagle, I tried .NoDlay = True, still no luck.I will try TcpClient.

Perhaps since you're using TCP, the Nagle algorithm is buffering the stream for efficiency, and your message is too short so is stuck in the buffer waiting for more byte stream before sending.
After your creation of tempSocket, you can try adding

tempSocket.NoDelay = True

to disable Nagle, and the data should be transmitted without consolidating multiple send calls into one transmission.

Haven't tested it. I've only used TcpClient class (System.Net.Sockets.TcpClient), and haven't experience any issues with data not being sent with that. I'm just guessing since you say you don't see the data going out, that Nagle may be a possible reason.

I already had a program that would wait for a TCP connetion, and read bytes from the stream, initially 4 bytes to get the size of the data coming and then it would read the data. The waiting for connection, then reading data ran in a background thread for simplicity.

I just tried a quick test of sending four bytes over a TCP connection to that application, from a console application using your code as an example, and I received the four bytes. I didn't need to set NoDelay, so I couldn't verify there was a problem, and that setting NoDelay would get around it.

Imports System.Net.Sockets
Imports System.Net

Module Module1

  Sub Main()
    Dim status As String = testSocket()
    Console.WriteLine(status)
    Console.ReadKey()
  End Sub

  Private Function testSocket() As String
    Dim s As Socket = ConnectSocket("127.0.0.1", 3030)
    Dim bytesSent() As Byte = {49, 50, 51, 52}

    If s Is Nothing Then
      Return "Connection failed"
    End If
    ' Send request to the server.

    Dim numSent As Integer
    numSent = s.Send(bytesSent)
    Return ("Bytes Sent")

  End Function

  Private Function ConnectSocket(server As String, port As Integer) As Socket
    Dim s As Socket = Nothing
    Dim hostEntry As IPHostEntry = Nothing

    ' Get host related information.
    '  hostEntry = Dns.GetHostEntry(server)

    ' Loop through the AddressList to obtain the supported AddressFamily. This is to avoid
    ' an exception that occurs when the host host IP Address is not compatible with the address family
    ' (typical in the IPv6 case).
    '  Dim address As IPAddress

    '   For Each address In hostEntry.AddressList
    Dim endPoint As New IPEndPoint(IPAddress.Parse(server), port)
    Dim tempSocket As New Socket(endPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp)

    tempSocket.Connect(endPoint)

    If tempSocket.Connected Then
      s = tempSocket
      '     Exit For
    End If

    '    Next address

    Return s
  End Function

End Module

Perhaps because I was using the local loopback IP address, Nagle doesn't get used because the data wouldn't actually go out the NIC, so Network efficiency doesn't really apply. The test could be invalid. But, I don't feel like setting up another computer on the network to do more testing, as I should be heading to bed anyway.

[Niya]

I don't think Nagle's algorithm is the problem here. I'm not even sure the problem is on this side. This is looking like a problem on the other end of that connection. The server isn't sending anything back. I'd look more closely at what is happening on that end if I were you.