Serialize TCP Reference Usage?

[NathanJD]

Do I need to serialize the usage of my TCP reference?  I.e. Do I need to control the access (using semaphores) to my TCP reference when using the reference in multiple processes?  Does the answer change when only considering read versus write?

I realize that I can create a queue and process to manage all my writes to TCP but that method does not work in my situation.

[crossrulz]

It isn't the write only TCP that would be a problem.  The problem I can see is the write and then get a response.  You could be interrupting your querry.  And speaking from experience, this is an issue.  My recommendation is to create an Action Engine that does your write and read.  The actions I can think of that you will want are Initialize, Write, Querry (does the write and read), Read, and Close.  This Action Engine works as your semephore and you do not have to pass the TCP reference around since it can just be stored in the Action Engine.

[nathand · Accepted solution]

You do not need to serialize access to TCP Write, so long as you don't care about the order in which messages are sent. You won't get pieces from two different writes interleaved with each other. However, as Crossrulz mentioned, you will have a problem with TCP Read if you need to match sent messages with received messages.

If you are not using a command-response architecture, it might be reasonable to put TCP Writes wherever needed, but do all TCP Reads in a single loop, and whenever a status update comes through, send it to all interested parts of the code through a notifier or a functional global variable. The only problem with this is that if the TCP connection dies, and you need to reconnect, then you'll need some way to update the TCP refnum everywhere.

[NathanJD]

In my application, there are only reads and writes, no querying i.e. I write a stream of data and receive a stream of different data.

What I'm currently writing is a hardware abstraction layer using LVOOP with DVRs as my private data containing the references (one device is based on TCP and others are typically going to be device specific DLLs).  I actually just realized that my current code already handles multiple writes because my "Send Message" method is non-reentrant and is the only method used for writing via TCP.  But, that still means that I could have reads and writes occuring at the same time since they are different methods of the class.

[NathanJD]

---

@nathand wrote:

If you are not using a command-response architecture, it might be reasonable to put TCP Writes wherever needed, but do all TCP Reads in a single loop, and whenever a status update comes through, send it to all interested parts of the code through a notifier or a functional global variable. The only problem with this is that if the TCP connection dies, and you need to reconnect, then you'll need some way to update the TCP refnum everywhere.

---

This basically describes my use-case perfectly (order only matters in that M2 must come after M1 but the messages need not be sequential; e.g. CAN communication).  Handling my reference is my LVOOP-based hardware abstraction layer with DVR private data.

Thanks!

[nathand]

---

NathanJD wrote:

But, that still means that I could have reads and writes occuring at the same time since they are different methods of the class.

---

That's fine, TCP is full-duplex communication. The TCP stack will not have a problem reading and writing at the same time (the operating system may handle it by serializing access at a low level - but you don't need to care about that). As previously mentioned you do want to avoid multiple reads at the same time since you have no idea which one will complete first. If your read follows the common pattern of reading a length followed by the actual data it could be especially problematic.