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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c58b7bd180ea81b2 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.k-dsl.de!feed.xsnews.nl!border-3.ams.xsnews.nl!82.197.223.104.MISMATCH!feeder4.cambrium.nl!feed.tweaknews.nl!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Problems with Ada.Streams.Read (blocking) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1c7gwe0hi3ew5$.1c9zms1qkzjel.dlg@40tude.net> <150pczbbk7gb2$.1ashrop4xh1b.dlg@40tude.net> <05f1c5d4-f673-40f5-9aee-dd1fa650a7b6@x35g2000hsb.googlegroups.com> Date: Sat, 9 Aug 2008 09:30:08 +0200 Message-ID: NNTP-Posting-Date: 09 Aug 2008 09:30:09 CEST NNTP-Posting-Host: fe768985.newsspool3.arcor-online.net X-Trace: DXC=:hOF;_Rj@BO=8m7nZkdN^@McF=Q^Z^V3H4Fo<]lROoRA4nDHegD_]REOU1J>Z^i]HJ[6LHn;2LCVN[ On Fri, 8 Aug 2008 14:25:33 -0700 (PDT), Maciej Sobczak wrote: > On 8 Sie, 20:51, "Dmitry A. Kazakov" > wrote: > >> You never reach the end of a TCP/IP stream unless the client closes the >> socket, which is usually indicates an error. > > This is not true. There are lots of protocols that use the end-of- > stream as an indicator of the end of request group. I meant Ada stream associated with the socket. You cannot end it otherwise than by closing the socket, if at all. I didn't look into GNAT sockets, but it is well thinkable that it implementation never ever ends the stream and instead of that raises Socket_Error upon an I/O on a closed socket. > In such protocols > the client is free to issue new requests whenever he likes and the > server will dutifully *wait* for each of them. No, that is full-duplex communication, which technically is not client-server. But in this case too, end of stream is never used to bound a request or response. It would be wasting resources. Worse than that, it would make the protocol unusable for the cases where the connection cannot be dropped, like serial communications, CAN bus, etc. >> The point is that you should never care about the stream end. > > The point is that end of stream indicates that the client is not > interested in interaction anymore. This is a valid protocol state. (OP designed a client) > This is different from the client's perspective, but I can imagine > protocols where the server can respond with potentially endless > answer, not necessarily continuous in time (online stock price > updates?), and finish after a timeout or some other even that is > outside of the client's control. Again, end of stream is a valid > protocol state. Surely, the network protocol for data exchange I designed for a middleware has exactly this design. Many other protocols used in automotive industry are of full-duplex asynchronous nature. But end of stream is never used there, otherwise than to indicate broken connection. >> If you correctly implement the protocol your application will never block > > Your application can also block if the other party blocks in the > middle of responding. You cannot fully control it. Yes, I wrote "unless server is busy." This is not blocking. Compare it with the way Ada defines a potentially blocking operation. A non-blocking operation is not meant instant, it is time-bounded. Delays caused by network latencies, server load etc semantically are not lookups. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de