You don't need to do anything special to wait.
Just read what is expected from the socket (or the network stream, if you use
TcpClient, which I would recommend). The reading methods behave as
blocking method calls. When the data is not yet sent by the other side, your calling thread will be
blocked at this call until the data arrives; and the thread will be put in a special
wait state where it does not waste any CPU time. The thread will be switched off and not scheduled back to execution until it is waken up. It will be waken up when the data arrives, or on some other events, notable timeout or thread abort.
More exactly, you should better explicitly define some
application-layer protocol (perhaps define it based on some documentation on your medical equipment) and implement it. Many developers implement actually working network solution without realizing that this is a protocol, but it's better to realize it and define explicitly. Then your application simply writes and reads the data according to the protocol, and gets blocked if the other side is not yet ready. Of course, this applies to the application-layer protocol on top of a
session-oriented
transport protocol, such as TCP. See also:
https://en.wikipedia.org/wiki/Application_layer[
^],
https://en.wikipedia.org/wiki/Transport_layer[
^],
https://en.wikipedia.org/wiki/Transmission_Control_Protocol[
^].
You may say that it would render UI unresponsive. Of course it would if you use just the UI thread. But that said, you should never use the UI thread for any activity related to communications with any external devices. You should always create some separate thread and dedicate them to communication. The the UI should work with your communications based on
push technology: your communication thread(s) should notify the UI when it is required. It is done using the
Invoke or
BeginInvoke methods of
Control or
Dispatcher. (This Dispatcher is a WPF feature, but this is one of the rare WPF features which can be directly used in a
System.Windows.Forms UI as well; this fact is not very well known.) Please see my past answers:
Control.Invoke() vs. Control.BeginInvoke()[
^],
Problem with Treeview Scanner And MD5[
^].
For further considerations related to socket-based communications and threads, please see my past answers:
an amateur question in socket programming[
^],
Multple clients from same port Number[
^],
How Do I Get To Know If A A Tcp Connection Is Over[
^].
See also my past answer related to push technology and threading:
Application 'dashboard' for website accounts[
^].
—SA
Submit an article or tip