This is all possible. For the port, use the class
System.IO.Ports.SerialPort
, see:
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx[
^].
In your case, you should do all the port I/O operation is a separate thread and just read from it. The call is blocking: you thread will be in a wait state (using zero CPU time) until data arrives and wake it up. Of course you can also always check up if the buffer is empty or not, using the property
System.IO.Ports.SerialPort.BytesToRead
.
However, your requirement "until the buffer is empty" is not really correct. More exactly, it all depends on what happens on the other end of RS-232 cable. This moment the buffer is empty, but in a minute, that end starts to transmit data again. In general case, your code should listen for the data all the time, during full run time of the application. I think you did understand it.
For pipes, see this CodeProject article:
Inter-Process Communication in .NET Using Named Pipes, Part 1[
^].
You can also use pipes indirectly, through the IPC channel in classical remoting or WCF. Such channels use named pipes for the implementation in a way transparent to the other aspects of the communication.
—SA