SO_REUSEPORT in LabVIEW

[JordanJMcBain]

HI,

I have a situation where I would like to have one consuming TCP port attached to two producers (with different IP's and local ports).  The means to do this appears to be to set the SO_REUSEPORT option in the Labview.ini file.  I can only find examples of this practice when people are using Linux or in obscure google search results. 

Does  NI have a position on this option and its use?

[TheXiadow]

Do you mind if I ask why you are trying to do this? In most cases, TCP is used for point-to-point communcation. I've never worked with multiple talkers and one listener.

Have you tested it out at all?

[JordanJMcBain]

For each process I have, I have only one queue on which they block.  I am trying to build a TCP interface to my architecture.

LabVIEW has no means of blocking on more than one operating system mechanism.  So if I want my network process to poll the TCP port and that process' designated queue, I will have to provide time outs in order to switch back and forth between them with unnecessary context switching. 

My thought was to open a TCP port or regular communication between two networked hosts and to also open another port on the local PC (127.0.0.1) to the former local networked port; when I want to send something over the queue, I would enqueue the data and then send a TCP "nudge" message to my sleeping process - no longer engaged in needless polling and context switching.

I have not attempted to implement this as I am not certain as to whether or not it is advisable.

Opinions are welcome.

[TheXiadow]

Regarding SO_REUSEPORT, to the best of my knowledge, I do not believe it is a public .ini token that can be accessed on Windows systems. I'm not sure I have a clear idea of what you're trying to do, but it sounds like a situation in which a producer/consumer architecture might be helpful. 

Good luck with your development!

[JordanJMcBain]

Producer/consumer will not address the issue.  The consumer loop invariable needs to check to see if an exit command was received.  Other commands/data also might need to be passed to the consumer loop which would require the consumer loop to poll various data transmission mechanisms.  This wakes up the thread unnecessarily, causes unneeded context switching and polling of multiple schemes.

I am able to address this later problem in all of the other threads of my design pattern.  However, the process which monitors networked ports for the architecture still suffers from this issue.  My proposed means of handling this issue is this "sneaky treak" I've suggested with SO_REUSEPORT.

I was hoping that turning on SO_REUSEPORT would allow me to sneak a wakeup message from one networked computer to itself to let itself know that data is waiting on the other messaging scheme.  If I can do that, then I can ensure that all threads are sleeping unless there is actually something for it to do.