TCP Communications Issue RRS feed

  • Question

  • I hope this is the proper forum for this question.

    I have an application which regularly obtains data from hardware PLC's over a TCP channel.  I am trying to test changes to this application on my development PC, which does not have the proper connectivity to the source data.

    I know little about TCPIP, but was hoping to simulate the output of the hardware devices using a small test application.  Both applications are using System.Net.Sockets classes.

    Can't I simply establish the TcpClient and Stream using a known IP address and port, then do writes to the stream, while the other program uses its own TcpClient and Stream to continuously read that channel?  Both TcpClients would use the same IP address and port.

    The problem I'm encountering is that when executing the following statement:

    Dim dc As TcpClient = New TcpClient(address, port)

    (where address and port are the proper values), the statement times out with this error:

    "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

    I tried running the receiving program at the same time, thinking that both programs would need some type of response from the other in order to open the connection.

    I can't seem to get this to work.  Is it even possible to test a TCP client in this manner, or do I need to hook my development PC up to the actual hardware which is broadcasting the information?


    Ron Mittelman

    • Moved by Mike Feng Thursday, March 7, 2013 2:49 AM
    Wednesday, March 6, 2013 12:14 AM

All replies

  • You can't just use TcpClient to do 2-way connection.

    If you're trying to do simple peer-to-peer connection, I'd suggest you to use TcpListener to listen to a local port, then try to connect to the remote port. You can gather the TcpClient from the listener through AcceptTcpClient() method.

    Either set the rule that the first who connect wins (loser drops listener accquired TcpClient even if already connected. So only one connection is maintained at the same time.), or allow 2 concurrent connections (You should determine which is more desirable for you yourself.).

    Wednesday, March 6, 2013 2:49 AM
  • Thanks for the information, Cheong.

    I guess I will not be able to use a test program in that case.

    You see, the application, when plugged in to the hardware being monitored, will indeed read the data sent by the hardware.  This has bee working for some time..

    I was hoping to be able to test enhancements to the application right from my development PC, without having to be connected to the actual hardware.  I don't understand why it won't work by running a simulation program to supply data packets, but I will need to live with that.

    Thanks again...

    Ron Mittelman

    Wednesday, March 6, 2013 6:36 PM
  • I believe you can do the simultation if you do the following

    1) Server - Start server up first using the loopback address (IP.Any) as the listening port (end point)

    2) Client - Use the IP address of the PC as the end point and connect to the Loopback address as the destination.

    There are a few rules that must be maintained when making a TCP connection.  A connectoin consists of a Source IP address, a Destination IP address, and a Port number

    1) The source and destination IP address must be different.

    2) The Client end of the connection cannot use the Loopback address as the source IP address, otherwise, the far end of the connection will send the return message to itself instead of sending to the far end of the connection.


    Wednesday, March 6, 2013 8:05 PM
  • Err... This needs a few corrections or clarifications.

    First, IPAddress.Any is, not ( is the loopback address for IPv4).

    Second, unless in some very rare circumstances where "your side" of machine has multiple NIC that have address in same subnet but none of them are default, there's no need to set the source IP of TcpClient. Just leave it to default (any) should be okay.


    Btw, if you want to drain data from the datasource, I'll suggest you try to connect the datesource using the original software and use packet-sniffing software like WireShark to capture the activity in between.

    I once was required to reverse engineer the a card reader's provided software to integrate the device into our HR system (although it used COM port with patched cord), and found the capturing side should send "Vxx1y" as response to the reader for each message it received (the xx is the controller device id and y is the reader's sequence number to the controller). You could see there's similiar lame requirement.

    Thursday, March 7, 2013 1:14 AM
  • chenong00: I totally disagree with you about IPAddress.Any. is a mask a not a IP Address.  Ethernet requirement is that every device MUST have a loopback address which is used as a listening port for incoming traffic.  Address is not a port and cannot be used to recieve data, you must use the loopback for this purpose.  A computer doesn't have a port with address


    Thursday, March 7, 2013 10:18 AM
  • Regarding IPAddress.Any, even if you don't trust the MSDN documentation, running "netstat -na" once will show that what you've written here is wrong.

    Having TcpListener listen with local address set to have only one effect - everyone except your local machine cannot access the port opened by the listener.

    "" is known as "address wildcard" and is only legal to be specified on listening side, meaning "I'll listen on the specified port of every NIC/IPs on the machine".

    Thursday, March 7, 2013 11:05 AM
  • Hi RMittelman,

    When creating a listener, is used to allow connections from the local machine. If you want to allow connections from remote machines, it is needed to use an IP address that is resolvable by the remote machine.  This is usually the IP address assigned by your network administrator, and you can use ipconfig -all to find it. Also, can be used, which means your listener will listen on all addresses assigned to the server (for example, a wired connection address, a wireless connection address, etc.). The client, on the other hand, must know the server's IP address. It cannot use (unless the client and the server are on the same machine), or (which does not apply to client).

    Best Regards.

    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, March 15, 2013 1:01 AM