Re: Ada Networking (General/Design)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 13 Aug 2012 19:11:30 +0000 (UTC), tmoran@acm.org wrote:

>>>> If Ada provided higher level socket library with an integrated support of
>>>> protected objects and tasks...
>>>   What do you mean?
>>
>>The most difficult and unavoidable part about socket programming is
>>tasking. We need reader and writer tasks or else socket-select-driven
>>co-routines. The reader and writer parts have to communicate each other in
>>some intricate way because it is two tasks but one protocol state machine,
>>or one task and many state machines in the case of socket select. There is
>>the issue of blocking socket I/O non-abortable by Ada means. All this
> 
> The Claw.Sockets package has a simple Socket_Type with
>   procedure Open(Socket     : in out Socket_Type;  -- or Server_Type
>                  Domain_Name: in     String;  -- or Network_Address_Type
>                  Port       : in     Port_Type;
>                  Timeout    : in     Duration := 30.0);
> and Text_IO style Get/Put for Strings, Input/Output for streams, etc.
> It also has a non-blocking Async_Socket_Type with overridable
> When_Connect, When_Readable, etc routines, but I find using blocking
> sockets with tasks whose structure encodes the state machine is much
> simpler.  All the blocking socket routines allow a timeout parameter,

In an Ada friendly way they should be entry calls, with the semantics of
canceling the request when a timed entry call gets timed out. That is when
the socket is blocking:

    select
        Socket.Receive (Packet);
    or delay 10.0;  -- Failed to read
    or terminate; -- Yes I know, it is illegal to have terminate + delay
    end select;

Or maybe other way round, they should be "entry points" to which socket I/O
could call to.

For non-blocking I/O there should be a way to have a pseudo-task ran by the
events on the socket, rather than scheduled.

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