Re: Control flow design question
On 22.06.2009 15:05, Eric Sosman wrote:
JannaB wrote:
I have a sockets server, listening on a single port for connections of
from 1 to 400 different terminals on the internet.
These terminals are grouped into what I call "channels." That is,
terminal 1,5 and 119 may be all from channel "A."
I only want to process 1 channel at a time. In other words, if I get a
signal from terminal 5, and one from 119, the latter must wait until
the former is processed. (Incidentally, I don;t write out from the
sockets server, rather, it writes some JSON data that is ultimately
transmitted back to the appropriate channel terminals).
Each connection to my sockets server will be making some JDBC inserts
and undates.
I am wondering, structurally, how best to handle this, realising that
archtiectural questions such as this are best handled properly from
the outset. Thank you, Janna B.
My first thought would be to use a different incoming
socket for connections on each channel, then write what
amounts to an ordinary single-threaded one-request-at-a-time
server for each channel's socket. But if you've got to use
the same IP/port for all the clients, that won't work.
That does not exactly meet the requirement as stated above: OP said that
he wanted to process only one channel at a time. It may be though that
he meant that he wants to process only one event at a time _per channel_.
Another approach would be to maintain N queues of requests,
one for each channel. A single thread accepts incoming
requests on the single port, figures out which channel each
belongs to, and appends each request to its channel's queue.
Each queue's requests are processed by one dedicated worker
thread.
Yep. That would be my favorite although I have no idea how the channel
is obtained from the connection.
A disadvantage of the second approach is that it forces
you to have the same number of worker threads as channels,
which might not be convenient (the one-request-per-channel
requirement means you can't have *more* workers than channels,
but if the channel count is large compared to the "CPU count"
you might well want to have fewer). Instead, you could have
N queues as above but just M worker threads: A worker finds
the queue with the oldest (or highest-priority) request at
the front and processes that request, but during the processing
it marks the queue "ineligible" so no other worker will look
at it. When the queue's first request is completed, the queue
becomes "eligible" again and the worker repeats its cycle.
In that case I'd rather have M queues and M workers and put something
into the event that is enqueued which allows detection of the channel.
Then place events for multiple channels in one queue.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/