Sending data via sockit

Hi

Is there a way to make SOCKIT work with UDP instead of TCP?

cheers

Silvan

Not unless you make changes to the XOP yourself.

I think I might have found a workaround

The idea is to sent a unix command from Igor executing a netcat routine to dump the data into a text file, then use Igor to pick it up from there. 
 

Unfortunately, I run into a problem that when I execute this. The netcat needs to be terminated manually by either pressing CRTL + c or by sending the command 

Unfortunately Igor is stuck in the "listening mode" and cannot send that kill command. 

Any idea how to force Igor to abort that command and continue in the script?

Cheers

Silvan

I have edited your last post to put the commands in an Igor Code Snippet. It's good for more than just code.

You should be able to kill the process started by ExecuteScriptText by pressing Ctrl-Break or Shift-Esc (which I added when I got a keyboard that didn't have the Break key). Break may be labelled "Pause".

Your /W flag establishes a pretty long wait time. You might want to shorten it to something less than almost 17 minutes.

yes, but how can I avoid pressing Ctrl-Break or Shift-Esc, since I want this to run continuous, picking up the value in the txt file every second?

It seems ExecuteScriptText waits for a very long time (1000 s) here. I don't know the details of your approach, but can't you just set this to a very small time (<1 s) and let Igor break out immediately? If you are waiting for some kind of response, then this should be separated into another function, i.e., have a separate sender and listener. Are you using a background task within Igor for the communication? => If not, then that's the first thing you should look into:

Unfortunately it still doesn't work this way. I created two functions DemoUnixShellCommand() and DemoUnixShellCommand2(), one to start the listening process on the port 4450, and the other one to terminate it. However, when I execute the DemoUnixShellCommand() even as a background task, Igor get's stuck in the listening mode and does not execute any further background tasks to abort the listening mode. Any idea how to change that?

I have no experience with ExecuteScriptText, but in the manual the following is written:

For non-GUI programs, if you specify a positive value for waitTime, ExecuteScriptText waits up to that many seconds for the command to complete. If the command fails to complete within that period of time, ExecuteScriptText returns an error. If you omit the /W flag or if you pass zero for waitTime, ExecuteScriptText waits until the command completes no matter how long it takes. If the script being executed creates a Windows command window, via cmd.exe for example, the Windows process completes only when the command window closes, not after the script commands execute.

 Maybe you have to make sure that the shell script closes the command window via exit or something?

silvan.roth wrote:

yes, but how can I avoid pressing Ctrl-Break or Shift-Esc, since I want this to run continuous, picking up the value in the txt file every second?

Based on the paths in your code snippet I assume you are running on macOS. As documented in the ExecuteScriptText command help, the /W flag is accepted but ignored on Macintosh. So you can't tell Igor to use a timeout on macOS.

I think you can get this to work if you use these two functions to start and stop listening:

You would then start a background task that polls the file. You probably want to keep a global variable that stores the number of bytes in the file that you have already read/processed. In your background task you would open the file, set the position to the previous end position, read the rest of the file, store the new end position, and close the file. Look at the command help for Open, FBinRead, FStatus, and FSetPos.

Well, the code works, but only once, after that I have to send another set of StartListening() and StopListening(). If I now put this in a Loop, it completely spams me with Terminal windows. 
Let me explain the whole task: I have a device pushing with about 10Hz values over the UDP port 4450. I want to read these values with Igor and store them in a wave. Since I cannot directly read UDP with Igor I thought of going via a txt file, constantly refreshing it. Another possible way I see is forwarding the UDP port to a TCP port. Igor should be able to read from that

silvan.roth wrote:

Well, the code works, but only once, after that I have to send another set of StartListening() and StopListening(). If I now put this in a Loop, it completely spams me with Terminal windows. 
Let me explain the whole task: I have a device pushing with about 10Hz values over the UDP port 4450. I want to read these values with Igor and store them in a wave. Since I cannot directly read UDP with Igor I thought of going via a txt file, constantly refreshing it. Another possible way I see is forwarding the UDP port to a TCP port. Igor should be able to read from that

Since your question no longer involves the SOCKIT XOP, it's probably best if you create a new thread to continue discussion.

However at this point, I think you have a UNIX problem, not an Igor problem. If you execute the following in terminal, do you get a continuous supply of messages, or just one message?

If you only get one message, you need to figure out a command that gives you a continuous stream of messages. Here is a command that might give you something closer to what you want:

That will print the header and some other information that you probably don't want, but with sufficient UNIX fu you should be able to get all that stripped off. https://serverfault.com/questions/206734/how-do-i-make-tcpdump-not-prin… gives some suggestions that might work. Otherwise you can just dump all of it to the text file and extract the data itself in Igor.

The way I've usually dealt with UDP data is to use python scripts to send/receive the data streams, write to a text file, and read the text file periodically with Igor as a workaround. I don't know if this is a possible solution in your case.

When applying the code above, a ew terminal is opened every time the command is called. Furthermore, you need to execute it as sudo, which means that for every datapoint you would have to enter the pwd. If you modify the code like this:

it resends the command to the same terminal again and again. 
Unfortunately, the output txt file is not readable by Igor as a notebook. Any Idea?

If you got to the point where a text file is constantly updated, and the remaining task is 'only' to watch this file and read its contents, I think you are almost there. Igor can do this easily. I guess the first task is to build a function which can parse the file contents. I guess the part you are interested in is the binary data after tcpdump, right? Do you know what to expect and how to parse the data? Look into FBinRead for loading the the binary data. If you got this part down, then you could write a background task which checks upon the file and load the latest output. Here is some pseudocode:

actually, I'm looking for that part in the file:
 

|1.375076;

that is the interesting value, the rest can be trashed

Oh, that's easy. Try this (assuming the value you are interested in is prepended by '|' and ends with ';'... if multiple such entries are contained it gets a bit more complicated):

As a test, execute: print/D readLog("thisStringIsAFilePath")

it works! thanks a lot!

However, it's really slow, since I have to wait for the file to be passed through UDPdump and being saved. I think there is no way around writing my own XOP for reading UDP values. Do you have a starting point for me?

Why are you using the -c flag with tcpdump? If you remove that flag then you shouldn't need to call the tcpdump command over and over.

Using the -w flag writes raw packets to file using the pcap file format. This is a binary file format, and doing what chozo suggested above might work but is risky.

Try this command:

When I use this command on my machine that has a device that sends UDP packets at around 1Hz, I see the size of the tcp.txt output file increase about once a second. The -l flag should force tcpdump to write the data to the file one line at a time, which is probably what you want. Polling for changes to that file's size from Igor and reading in the new data should easily be able to keep up with a 10 Hz device.

That works well, and the file is growing. If I now keep reloading the file, it will be soon slow. Can I delete the loaded lines in the file with Igor again?

silvan.roth wrote:

That works well, and the file is growing. If I now keep reloading the file, it will be soon slow. Can I delete the loaded lines in the file with Igor again?

Writing to a file from two different processes is a bad idea, if it's even possible.

I figured out how to get nc to work to capture multiple UDP packets to a file:

Depending on how long you capture data, that file will eventually get large. I'm not sure that will actually cause performance problems (unless it gets **really** large). You may need to capture to a different file periodically so you can finish reading the previous file and delete it.

Another approach you could consider (and possibly quickly reject) is to direct the output of nc directly to Igor. To test this, I pasted the following function into Igor's procedure window and compiled procedures.

I then executed this command in terminal:

This attempts to start a new Igor instance each time it is called, but since one is already running that instance takes the command. The device I'm using sends packets at around 1 Hz. Your 10Hz device might bog down the OS too much. Also, Igor prints the command into the history window and it's not clear to me that it's possible to prevent that from happening.

BTW, I'm testing this with a device that uses port 50222. You should substitute your port number.

Writing your own XOP might be an option if you are an experienced C/C++ programmer and if you are familiar with the UDP protocol.

You might be able to use the ZeroMQ XOP (https://github.com/AllenInstitute/ZeroMQ-XOP) to listen for UDP packets on a port. I don't know much about ZeroMQ and have never used the XOP.

it almost works sending the packets to Igor directly. When I paste the command in the terminal, nothing happens, the computer stays in listening mode. I close the terminal manually and reopen a new terminal and send the command killall nc. As soon as I send this, Igor receives a package.