From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: ANN: Ada/SPARK ASN.1 implementation version 0.0.01 Date: Mon, 1 Aug 2016 20:37:23 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <3ac0fbcd-1f1c-40b8-b030-de03954f894f@googlegroups.com> <3e053880-a0b9-4b58-9344-cc08a92ab9da@googlegroups.com> NNTP-Posting-Host: xelDFTENDI+dlkJFd2Ot2w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31240 Date: 2016-08-01T20:37:23+02:00 List-Id: 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