I fear that I am only writing posts here when I am pissed off at something.
However, that's not going to stop me from venting. :)
Ok, the topic today is communications programs, and a severe lack of understanding of a basic communications concept.
A typical inter process communications paradigm is the Client-Server. One process is up and running, with a well-known contact point; this is the server. Other programs, the clients, which can be short-lived, will connect to the server at the well-known point, send messages in, and the server will send responses. In many cases, the server is single purpose, like the Network Time Protocol servers run on many large networks, to provide a consistent time signal for all the other computers. But there is nothing that says a server cannot do other things as well.
But I ran across a developer recently who was confused by a program we have at work that is an intermediary in a chain of processes that communicate with external devices. Due to the need for handling many external devices, this program uses an asynchronous protocol, where the messages going out are not responded to directly by the device, but at some later time. So we have a zippered pair of protocols, where this program acts as a client to send a message to a device, and a server to receive the response from a device.
This developer was confused about this, noting that it was confusing that the one process was both a server and a client, when most were just one or the other.
I find it rather hard to believe that any developer with more than 4 years of communications programming work has not seen many, many examples of processes that talk to two or more other processes and act as client to one and server to the other.
I mean, is it just me, or is the idea that Client and Server are just roles a process assumes when it is communicating with another process, defined solely by who is originating the message?
The mind boggles.
However, that's not going to stop me from venting. :)
Ok, the topic today is communications programs, and a severe lack of understanding of a basic communications concept.
A typical inter process communications paradigm is the Client-Server. One process is up and running, with a well-known contact point; this is the server. Other programs, the clients, which can be short-lived, will connect to the server at the well-known point, send messages in, and the server will send responses. In many cases, the server is single purpose, like the Network Time Protocol servers run on many large networks, to provide a consistent time signal for all the other computers. But there is nothing that says a server cannot do other things as well.
But I ran across a developer recently who was confused by a program we have at work that is an intermediary in a chain of processes that communicate with external devices. Due to the need for handling many external devices, this program uses an asynchronous protocol, where the messages going out are not responded to directly by the device, but at some later time. So we have a zippered pair of protocols, where this program acts as a client to send a message to a device, and a server to receive the response from a device.
This developer was confused about this, noting that it was confusing that the one process was both a server and a client, when most were just one or the other.
I find it rather hard to believe that any developer with more than 4 years of communications programming work has not seen many, many examples of processes that talk to two or more other processes and act as client to one and server to the other.
I mean, is it just me, or is the idea that Client and Server are just roles a process assumes when it is communicating with another process, defined solely by who is originating the message?
The mind boggles.
1 comment:
A router is a very common case of client & server. Indeed, it is both a DHCP client and a DHCP server.
Post a Comment