How to Exchange Real-Time Data Between Two Computers Using MATLAB?

Hello everyone,

I am working with two MATLAB scripts running on two different PCs in the same network. I want to establish a connection between them so that they can exchange data in real time while both are running.

The goal is to send data continuously from Computer A to Computer B, and vice versa, with minimal latency.

Could you please advise on the best approach to achieve this?

Answer 1

[Dev]

Hi @MOSTAFA,

In MATLAB R2019a, we can perform real-time, bi-directional data exchange between two MATLAB scripts on different PCs using the TCP/IP stack. Specifically, we can use the legacy "tcpip" object from the "Instrument Control Toolbox" available in MATLAB for TCP/IP communication. Please refer to the steps below on how we can set up bi-directional communication between two PCs:

• Computer A: TCP/IP Server

We can create a server using the "tcpip" function in MATLAB by proving the actual port number where the server will listen. I have mentioned an example code snippet below of how to open a server connection-

% On Computer A (Server)
% Replace '30000' with your chosen port number
tcpipServer = tcpip('0.0.0.0', 30000, 'NetworkRole', 'server'); 

• Computer B: TCP/IP Client

Using the same "tcpip" function, we can create the client as well by providing the actual IP address of Computer A as the server IP. Please refer to the example below-

% On Computer B (Client) 
% Replace 'SERVER_IP' with the actual IP address of Computer A 
tcpipClient = tcpip('SERVER_IP', 30000, 'NetworkRole', 'client'); 

Once the server and client are setup, we can then perform data read/write using the "fread" and "fwrite" functions.

Additionally, the latest MATLAB versions post the R2021a release enable a much easier TCP/IP communication using the "tcpserver" and "tcpclient" functions. Please refer to the same in case the MATLAB versions you now use are updated.

Please find all the relevant documentation links from the latest release below-

"Instrument Control Toolbox"- https://www.mathworks.com/help/releases/R2024b/instrument/

"fread"- https://www.mathworks.com/help/releases/R2024b/matlab/ref/fread.html

"fwrite"- https://www.mathworks.com/help/releases/R2024b/matlab/ref/fwrite.html

"tcpserver"- https://www.mathworks.com/help/releases/R2024b/instrument/tcpserver.html

"tcpclient"- https://www.mathworks.com/help/releases/R2024b/matlab/ref/tcpclient.html

I hope the above explanation helps you to resolve your query.

[Walter Roberson]

Note that in newer MATLAB, tcpclient() is part of basic MATLAB, but tcpserver() requires the Instrument Control Toolbox.

Answer 2

[Walter Roberson]

The general mechanism is to use the Instrument Control Toolbox udpport. udp is a connectionless bi-directional protocol

If you do not have the Instrument Control Toolbox, you can use TCP/UDP/IP Toolbox from the File Exchange. That is an older toolbox, and it is not immediately clear whether it is still compatible with modern MATLAB.

udp is not high latency; packets are generally sent towards the destination soon after the packets are created.

udp is considered "unreliable". It is legal for udp packets to be dropped by anything along the line, and there will be no notification of dropped packets. It is also possible for udp packets to arrive out-of-order. udp packets are considered to be unordered; it is entirely possible for the received relative packet order to be 3 1 4 5 7 6 (with packet 2 never received.) Because of this, it is common for the programmer to add sequence numbers to the packets, to at least be able to detect missing or disordered packets, and is it common to make packets match up to complete "updates".

The main alternative it tcp. tcp is considered ordered. Sequence numbers are built into the TCP protocol, and the protocol itself will detect missing packets and will automatically send a request for retransmission. Because tcp packets might potentially get lost on the way (they will not be deliberately dropped unless dropped by security policy), it can end up being a while before resyncrhonization is finished, and there is nothing in the protocol that might correspond to "Never mind the lost packets, continue from here." Because of the automatic sequence numbering and automatic reordering of received packets, it is common for arbitrary streams of data to be sent across tcp, without paying attention to packet boundaries -- tcp automatically fragments larger blocks of data into packets.

If you have a low to medium timeout on receiving packets, together with logic to handle missing packets, then you need udp. As the timeout becomes indefinitely long then the advantages of TCP start looking very attractive.

[Walter Roberson]

Oh wait, in R2019a you would use https://www.mathworks.com/help/instrument/udp.html not the newer udpport