Re: ANN: Ada/SPARK ASN.1 implementation version 0.0.01

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

On 2016-08-01 18:18, Shark8 wrote:
> On Monday, August 1, 2016 at 2:51:56 AM UTC-6, Dmitry A. Kazakov wrote:
>> That means the TLS layer should write no more data than the output
>> buffer length, while keeping its internal state to continue when the
>> buffer becomes available, and the layer is called again.
>>
>> Same when reading data from the input buffer, data get available in
>> chunks of arbitrary size. If the layer expects more data, it must return
>> to the caller, again, keeping internal state.
>
> That's a good idea -- a task-type would probably fit the bill
> nicely,  keeping its own state for every instance.

No task types, please. That would defeat the purpose of the 
architecture. A non-blocking I/O allows multiple connections serviced by 
single task. A connection can also migrate from task to task, e.g. from 
a pool of working tasks.

The method is roughly [for single task scenario]:

loop
    wait for sockets from a set of sockets

    for Socket in sockets ready to read loop
       get connection object from Socket
       read Socket into input FIFO as much as possible w/o blocking
       pass FIFO (unprocessed chuck) to connection object
    end loop;

    for Socket in sockets ready to write loop
       get connection object from Socket
       if not output FIFO full then
          pass FIFO (free chuck) to connection object
       end if;
       write output FIFO as much as possible w/o blocking
    end loop;

end loop;

TLS layer would be a part of connection object. The decoded chunks would 
feed the higher layer. Its output would go back to TLS to encode.

As you see it is more complicated than blocking I/O. Though in the case 
of TLS it could not be very difficult because all packets have fixed 
length. So you possibly could keep internal input and output buffers in 
the TLS layer object.

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