Sharing a socket connection

Sharing a socket connection

[Jacob Sparre Andersen]

We are working on a system where a number of Ada tasks are going to
share a single socket connection to a server [1].

The socket connection is bidirectional with requests sent from a client
followed by corresponding responses from the server.  Each client should
only get responses to its own requests.

Our current approach is to encapsulate the socket in a package, and use
a mutex [2] to lock the socket during an entire
send-request-get-response operation.

Greetings,

Jacob

[1] The rationale for this is that the individual tasks only are
    expected to use the server sporadically, and that letting each task
    have its own connection may use too many limited resources on the
    server.

[2] Do the standard libraries include a mutex (I have a vague
    recollection of having seen one, but can't find it), or should we
    just implement it ourselves (or use the one in "Simple components
    for Ada").

-- 
Photo of the day:
                  http://billeder.sparre-andersen.dk/dagens/

Re: Sharing a socket connection

[Niklas Holsti]

On 12-07-31 11:56 , Jacob Sparre Andersen wrote:
> We are working on a system where a number of Ada tasks are going to
> share a single socket connection to a server [1].
> 
> The socket connection is bidirectional with requests sent from a client
> followed by corresponding responses from the server.  Each client should
> only get responses to its own requests.
> 
> Our current approach is to encapsulate the socket in a package, and use
> a mutex [2] to lock the socket during an entire
> send-request-get-response operation.

Why not use a "server" task inside the package, with rendez-vous in the
classical Ada style? The "server" task has a single entry, which has an
"in" parameter for the request from a client task and an "out" parameter
for the response. The accept statement for the entry sends the request
over the socket, waits for the response, and returns the response in the
"out" parameter. The "server" task body looks like this:

   loop
      accept The_Entry (Request, Response) do
         Socket_Send (Request);
         Socket_Receive (Response);
      end The_Entry;
   end loop;

This provides mutual exclusion between the client tasks within the
accept body, without the need for an explicit mutex.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Sharing a socket connection

[Dmitry A. Kazakov]

On Tue, 31 Jul 2012 10:56:21 +0200, Jacob Sparre Andersen wrote:

> We are working on a system where a number of Ada tasks are going to
> share a single socket connection to a server [1].
> 
> The socket connection is bidirectional with requests sent from a client
> followed by corresponding responses from the server.  Each client should
> only get responses to its own requests.

This sort of multiplexing will be extremely slow. Basically you block
communication until server respond.

> Our current approach is to encapsulate the socket in a package, and use
> a mutex [2] to lock the socket during an entire
> send-request-get-response operation.
> 
> Greetings,
> 
> Jacob
> 
> [1] The rationale for this is that the individual tasks only are
>     expected to use the server sporadically, and that letting each task
>     have its own connection may use too many limited resources on the
>     server.
> 
> [2] Do the standard libraries include a mutex (I have a vague
>     recollection of having seen one, but can't find it), or should we
>     just implement it ourselves (or use the one in "Simple components
>     for Ada").

If you look at the implementation there, it is quite simple.

My primary concern would making it full duplex multiplexed. Because
half-duplex communication is really one of the major performance killers.

I would consider a request [protected] object queued to a dedicated task
doing I/O. The object would be waitable for the task that queued it. Which
is basically how OS drivers work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Sharing a socket connection

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:
> Jacob Sparre Andersen wrote:

>> The socket connection is bidirectional with requests sent from a
>> client followed by corresponding responses from the server.  Each
>> client should only get responses to its own requests.
>
> This sort of multiplexing will be extremely slow. Basically you block
> communication until server respond.

Yes.  Fortunately that is not likely to be a problem for this
application.

> My primary concern would making it full duplex multiplexed. Because
> half-duplex communication is really one of the major performance
> killers.
>
> I would consider a request [protected] object queued to a dedicated
> task doing I/O. The object would be waitable for the task that queued
> it. Which is basically how OS drivers work.

I'm not sure I understand what you mean.  AFAIK protected objects can't
queue on entries.

Greetings,

Jacob
-- 
Photos from LinuxDay2005 in Cagliari:
                        http://linuxday.gulch.it/2005/album/

Re: Sharing a socket connection

[Dmitry A. Kazakov]

On Tue, 31 Jul 2012 13:50:31 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
>> Jacob Sparre Andersen wrote:
> 
>>> The socket connection is bidirectional with requests sent from a
>>> client followed by corresponding responses from the server.  Each
>>> client should only get responses to its own requests.
>>
>> This sort of multiplexing will be extremely slow. Basically you block
>> communication until server respond.
> 
> Yes.  Fortunately that is not likely to be a problem for this
> application.

Then I would do just what Niklas suggested.

>> My primary concern would making it full duplex multiplexed. Because
>> half-duplex communication is really one of the major performance
>> killers.
>>
>> I would consider a request [protected] object queued to a dedicated
>> task doing I/O. The object would be waitable for the task that queued
>> it. Which is basically how OS drivers work.
> 
> I'm not sure I understand what you mean.  AFAIK protected objects can't
> queue on entries.

Protected object is basically a signal. You can pass it to a task entry or
queue somewhere. The "driver" picks up a request and initiates I/O (e.g.
sends something to the server). Then it shoves the request to another
queue. Upon receipt, which is typically another task, the task takes the
request and signals it completed. The caller may see nothing of these
transitions just waiting for the event signaled.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de