[Tutor] socket communications and threading

Alan Gauld alan.gauld at btinternet.com
Tue Oct 27 19:58:14 EDT 2015


On 27/10/15 17:51, richard kappler wrote:
> Sorry, thought it was clear. Each of the three different data 
> generating machines
> (in the test env, the python script that sends the data with 3 
> different device names)
> goes over a different thread so the developers tell me.

OK, You need to get the concepts clear.
Threads are about parallel processing. They occur on a processor and
have nothing to do with communications. They are one of several mechanisms
that enable multiple tasks to run in parallel on a single computer. Each 
thread
is a sub-process of the parent process. Its common, but not necessary, 
for the
threads to all be clones of each other, but they could equally be 
multiple different
types of process.

Sockets are simply communications channels. They connect two processes,
usually over a network but not necessarily. They have no direct 
relationship
to threads.

It is, however, very common to have different threads (different 
instances of
a process) handle each communication channel, but it's by no means 
necessary.

> in the examples I read, it was about which was server and which was 
> client,

As I said, client/server is about the nature of the communications 
between two processes
(which are often on two different computers but don't have to be). The 
nature of the client
and server processes is completely open, it could involve communicating 
over sockets,
but it might not. It could involve multiple threads, it might not. They 
key thing that defines
the relationship is that clients send requests to the server which sends 
responses back.
The server never sends requests to the client (if it did it would be 
peer to peer  not
client/server). The server may send unsolicited events (notifications) 
to its clients
(either broadcast to all or targeted at one) but it does not expect a 
response.


All of these concepts are separate and not dependant on each other. You 
could have
multiple client threads as well as multiple server threads, or no 
threads at all. It could
all run on a single computer, with or without sockets. In particular, 
it's common today
to use higher level comms mechanisms such as http with JSON/XMLRPC/SOAP. 
Sockets
are used under the covers but the programmer doesn't need to know.

So to summarize what I think is going on in your case, you have:

VM1
A single threaded client process running on a micro-controller sending 
requests
to a remote server (VM2)
Question:
is there really only one client controller or is it actually 3, one
per logged machine? How do the logged machines communicate
to the controller(s)?

VM2
A multi threaded server process running on a conventional computer
(a PC? Mac? which OS?) It receives messages from the client(s?) and 
allocates these
messages to one of three threads(sub processes) depending on message source.
The server then acts as a client process and sends requests to another 
micro
controller acting as a server(VM3).
Questions:
Are the messages to VM3 sent from the individual threads?
Do they all go down a single socket connection?
Or is there a top level VM2 process that forwards the messages to VM3?
Or is there in fact a 4th VM2 thread/process relaying the messages to VM3?
(perhaps triggered from a database? or as a polling process).

VM3
A single threaded server process that receives messages and analyses 
their content.
I don't know what it does with the result...

In each case the messaging is done over raw sockets.

Is that a fair summary?


PS.
You might find it helpful to look at my tutorial sections on inter-process
comms and network programming. It covers client-server on a single machine
then using sockets to extend it to two machines (but uses an 
alternative, simpler
form of multi-processing to threads). Its in Python 2 but should convert 
easily
to Python 3.

http://www.alan-g.me.uk/tutor/tutipc.htm

But converting the model to threads would not be difficult (and indeed was
planned for the, as yet unwritten, topic on parallel processing!)

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos



More information about the Tutor mailing list