Video transmission from one computer to another computer over TCP

[constructionworker]

I checked everything, it looks like it should be. I couldn't see what I missed.

[Bob_Schor]

---

@constructionworker wrote:

Network stream, I think, creates a problem in data transfer with an ethernet cable between two computers.

---

If you have two computers with Ethernet Ports and want to establish a TCP connection between them using a single Ethernet cable, you need to use a "Cross-over" cable.  The typical Ethernet cable, used to connect a Computer to a "wall TCP Port" that ultimately goes to an Ethernet router or switch does not supply the needed "crossing" of the signals.

An alternative to using Cross-over cables (which might not work when you want to "plug into the wall") is to buy an inexpensive 4-port router and use two Ethernet cables, one to Computer A, the other to Computer B, and let the router figure out how to configure the connections properly.

I'm travelling, so I can't look at and test your code, but will try to get to it soon.

Bob Schor

[rolfk]

---

@Bob_Schor wrote:

---

@constructionworker wrote:

Network stream, I think, creates a problem in data transfer with an ethernet cable between two computers.

---

If you have two computers with Ethernet Ports and want to establish a TCP connection between them using a single Ethernet cable, you need to use a "Cross-over" cable.  The typical Ethernet cable, used to connect a Computer to a "wall TCP Port" that ultimately goes to an Ethernet router or switch does not supply the needed "crossing" of the signals.

---

Actually, unless you use pretty old computers and/or network interface cards, they all support nowadays Auto-negotiation MDI-X detection and do not really need a crossover cable anymore. I believe that any hardware not older than 10 years or so should be safe. 

[Bob_Schor]

---

@rolfk wrote:

---

@Bob_Schor wrote:

---

If you have two computers with Ethernet Ports and want to establish a TCP connection between them using a single Ethernet cable, you need to use a "Cross-over" cable.  The typical Ethernet cable, used to connect a Computer to a "wall TCP Port" that ultimately goes to an Ethernet router or switch does not supply the needed "crossing" of the signals.

---

Actually, unless you use pretty old computers and/or network interface cards, they all support nowadays Auto-negotiation MDI-X detection and do not really need a crossover cable anymore. I believe that any hardware not older than 10 years or so should be safe. 

---

Oops!  I'm showing the "age of my computers".  But now that I think about it, I can't remember when I last saw a Crossover cable.  I do remember they tended to be of questionable reliability, and when we hooked up those old Windows XP/Windows 7 PCs to old PXI systems, we always invested in a $30 4-port hub, with excellent results. 

Glad there's one less thing to worry about ...

BS

[constructionworker]

Rolfk  and  Bob_Schor

Both computers I use have ethernet ports. By the way, the only problem occurs when using "Network Stream". When using "TCP" directly, data can be exchanged without any problems. The application I want to create right now
- If the server is turned on and the client is still not open, the server must wait to read data from the client.
-If the Client is started and the Server is still not connected, it should wait for the Server to connect.
-If the client VI is stopped, it only notifies the Server VI that it is shutting down and does not cause the Server VI to shut down when it is shut down.
Can an application be created in this way with TCP?

Could following a method like this cause certain protocol errors?

I've been struggling for a while, I couldn't create it.

[Mark_Yedinak]

I have already provided you with 90% of the solution. I am not sure why you are totally ignoring it and continually asking the same question over and over. I have provided at a minimum the foundation for what you need. In fact, the server does exactly what you ask. The client would have to be modified to continue to retry to connect to the server however this is trivial to add to what was provided. I honestly don't know where you are struggling with this.

BTW, my personal preference is to use basic TCP for the communications. Network streams are proprietary to NI. Basic TCP with my own or some standard protocol on top of it is much more flexible and allows applications written in other languages the ability to also connect to the system. Network Streams will be a LabVIEW only implementation. Also, network streams are peer to peer. Basic TCP can be implemented to be peer to peer communications or support multiple clients. Again, much more flexible.

As to the general question of whether this can be done or not the answer is most definitely yes. I have a large distributed system that I developed that has been running 24/7/365 for years out in the field. It contains multiple servers and clients and all are fault tolerant.

[constructionworker]

---

@Mark_Yedinak wrote:

I have already provided you with 90% of the solution. I am not sure why you are totally ignoring it and continually asking the same question over and over. I have provided at a minimum the foundation for what you need. In fact, the server does exactly what you ask. The client would have to be modified to continue to retry to connect to the server however this is trivial to add to what was provided. I honestly don't know where you are struggling with this.

BTW, my personal preference is to use basic TCP for the communications. Network streams are proprietary to NI. Basic TCP with my own or some standard protocol on top of it is much more flexible and allows applications written in other languages the ability to also connect to the system. Network Streams will be a LabVIEW only implementation. Also, network streams are peer to peer. Basic TCP can be implemented to be peer to peer communications or support multiple clients. Again, much more flexible.

As to the general question of whether this can be done or not the answer is most definitely yes. I have a large distributed system that I developed that has been running 24/7/365 for years out in the field. It contains multiple servers and clients and all are fault tolerant.

---

I can't run the example you gave. I'm trying to debug but I'm missing something somewhere.
I'm not ignoring your solution anyway, my priority is to build with TCP.
- What I especially want to do is a client and server application like UDP that can work independently of each other, because I plan to run Client VI as soon as the computer is used, I want it to establish a connection with the previously running Server. . .
I really, really tried many methods and couldn't get the client to connect to the running server. It keeps crashing and I'm still struggling with it I've gone through almost all the examples given.

I am getting an error like this

if i change it like this. This time i get an error like below.

[Mark_Yedinak]

Is your client using the correct port and IP address? The error you are getting means the client is trying to connect but there is no server accepting connections for the port the client specified. The client I provided does not continually try to connect to the server. You would need a basic state machine, similar to what the server is doing, which will continually attempt to connect to the server. You need to add error handling in your code to ignore errors in the client and then attempt to connect again after some brief idle time. This is exactly what the server is doing. Once it creates the listener it will always return to waiting for a connection once a client disconnects. The server I provided does not support multiple clients at the same time. If you are trying to start more than one client this would explain the error you are getting. The other thing you would need to look at would be the firewall on the computer with the server. It may be blocking the port that the server is using. Have you confirmed that the server is up and running? If you place a probe there you should see if create the listener and then continually go back to waiting for a connection until a client actually connects. Use probes on the error wire so you can see what is happening. The client I posted will not continue to try to reconnect if it fails to connect the first time. Again, adding a basic state machine to the client would implement this.

Why did you modify the recv message VI? The second error you are getting is because the data stream is not matching the cluster definition wired to the unflatten from string. Both the sender and the receiver should be using the same cluster typedef for the format of the input to the flatten to string and the corresponding unflatten from string.

[constructionworker]

---

---

@Mark_Yedinak wrote:

Is your client using the correct port and IP address? The error you are getting means the client is trying to connect but there is no server accepting connections for the port the client specified. The client I provided does not continually try to connect to the server. You would need a basic state machine, similar to what the server is doing, which will continually attempt to connect to the server. You need to add error handling in your code to ignore errors in the client and then attempt to connect again after some brief idle time. This is exactly what the server is doing. Once it creates the listener it will always return to waiting for a connection once a client disconnects. The server I provided does not support multiple clients at the same time. If you are trying to start more than one client this would explain the error you are getting. The other thing you would need to look at would be the firewall on the computer with the server. It may be blocking the port that the server is using. Have you confirmed that the server is up and running? If you place a probe there you should see if create the listener and then continually go back to waiting for a connection until a client actually connects. Use probes on the error wire so you can see what is happening. The client I posted will not continue to try to reconnect if it fails to connect the first time. Again, adding a basic state machine to the client would implement this.

---

-Currently it is set to "localhost" as I am testing it on the same computer.

-At the moment, I am trying to run the example you edited in the first step. Then I will try to add the fix that tries to connect to the server.

-I'm only testing with a client anyway.

--First I run the Server, then I run the client.

---

@Mark_Yedinak wrote:

Why did you modify the recv message VI? The second error you are getting is because the data stream is not matching the cluster definition wired to the unflatten from string. Both the sender and the receiver should be using the same cluster typedef for the format of the input to the flatten to string and the corresponding unflatten from string.

---

I haven't changed the Recv message.It is as you first shared.

[alexderjuengere]

using Client-Server.zip ‏131 KB from Mark's Message M1233232 with minor changes:

Spoiler

Server-v2.vi:

- renamed the second "send data" case in "Stop"

- linked typdef 'data' to 'C:\Program Files\National Instruments\LabVIEW 2020\examples\Data Communication\Protocols\TCP\TCP Multiple Connections\controls\TCP Multiple Connections Data.ctl' etc.


Client-v2.vi:
- removed imaq-vis to send empty images

proof of data transmission on both localhost and port 6341

1# start server-v2.vi via run button (and stop via FRontpanel ' stop Button' )

2# start client-v2.vi via run button

3# stop client-v2 via 'abort execution' button -  this will stop server-v2.vi, too (after clicking two times continue)

4# look at incremented "# of connections"

Spoiler

now, modify to your needs

if you move from your 1 computer localhost setup to a 2 computer setup, I recomment to use the freeware https://iperf.fr/ to find valid port pairs