Communications between two MatLabs (2): over socket

1 min read

Aaron Piccirilli
Aaron Piccirilli

After the previous blog post Communications between two MatLabs (1) over file, Aaron Piccirilli in our lab suggested a more efficient way to communicate between two matlabs, i.e. over socket. Below is the source code provided by Aaron:

udpSocket = udp('127.0.0.1', 'LocalPort', 2121, 'RemotePort', 2122);
fopen(udpSocket);
udpCleaner = onCleanup(@() fclose(udpSocket));
for ii = 1:100
    fprintf(udpSocket, '%d%f', [ii ii/100]);
    disp(['Sending ' num2str(ii)]);
    pause(0.1);
end
udpSocket = udp('127.0.0.1', 'LocalPort', 2122, 'RemotePort', 2121);
fopen(udpSocket);
udpCleaner = onCleanup(@() fclose(udpSocket));
    while(1)
    if udpSocket.BytesAvailable
        ii = fscanf(udpSocket, '%d%f');
        disp(['Received' num2str(ii(1)) '-' num2str(ii(2))])
    end
end

More words from Aaron:

I also wrote a couple of quick tests to compare timing by having each method pass 10,000 random integers as quickly as they could. Using UDP is over four times faster on my work machine, and would be sufficient to keep up with sampling rates up to about 900 Hz, whereas the file-based transfer became too slow at about 200 Hz.

Obviously these rates and timings are going to be system and data-dependent, but the UDP implementation is about the same amount of code. It has some added benefits, too. First is what I mentioned before – that this allows you to communicate between different languages. Second, though, is what might be more important: buffer management. If your data source is sending data faster than you can process it, even for just a moment, the UDP method handles that gracefully with a buffer. To get the same functionality with the file method you have to write your own buffer maintenance – not too tricky, but adds another layer of complexity and probably won’t be as efficient.

I did a similar timing test passing 40 floats each time (say for 20 channels of NIRS data) instead of a single integer and the timing did not really change on my machine.

I also tested the above scripts, and they work beautifully! I definitely recommend this method over the ‘file’ method. One thing to note: when you Ctrl-C to quit the program, remember to close the socket (fclose(udpSocket)) AND clean the variables (udpSocket, udpCleaner); otherwise you will run into the “Unsuccessful open: Unrecognized Windows Sockets error: 0: Cannot bind” error.

Note from Aaron:

One note: the onCleanup function/object is designed as a callback of sorts: no matter how the function exits (normally, error, crash, Ctrl-C), when the onCleanup object is automatically then destroyed, its anonymous function should run. Thus, the UDP connection should be closed no matter how you exit the function. This won’t work for a script, though, or if you were just running the code on its own in a command window, as the onCleanup object wouldn’t be automatically destroyed. I would just exclude that line completely if you weren’t running it as a function.


Don't want to miss new papers in your field? Check out Stork we developed:

nirs2img, create an image file from NIRS data

I was asked where to get nirs2img script. Here it is. The download link is at the bottom of this article. nirs2img is to...
Xu Cui
51 sec read

mergefile.m – a MatLab script to merge CSV files

My wife asked me to write a script to merge some csv files she has. Usually this can be accomplished by a simple command in...
Xu Cui
35 sec read

2 Replies to “Communications between two MatLabs (2): over socket”

  1. The UDP method is indeed (imho) way better suited than using the rather slow file system for data transmission. An alternative is using dedicated realtime streaming protocols, which basically implement the same but probably more efficient and/or flexible. There are many academic open-source protocols around, e.g. BCI2000 or the FieldTrip buffer, which is what we have implemented in our software. For more information see here http://www.fieldtriptoolbox.org/development/realtime/buffer (using a TCP/IP socket)
    During my PhD I worked with MEG data, which samples at 1200Hz or above (with 275 channels + several reference channels), and the buffer could still keep up with this. The best way would of course be to have this implemented on the data acquisition side (as we did in our software), as then a simple Matlab script (or a small program written in C/C++/Python/Java/what have you…) would be sufficient to retrieve the data temporarily. Such a general implementation is also very advantageous if someone wants to collect multimodal data, e.g. combining EEG and NIRS.

Leave a Reply

Your email address will not be published. Required fields are marked *