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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!postnews.google.com!x35g2000hsb.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Problems with Ada.Streams.Read (blocking) Date: Fri, 8 Aug 2008 14:25:33 -0700 (PDT) Organization: http://groups.google.com Message-ID: <05f1c5d4-f673-40f5-9aee-dd1fa650a7b6@x35g2000hsb.googlegroups.com> References: <1c7gwe0hi3ew5$.1c9zms1qkzjel.dlg@40tude.net> <150pczbbk7gb2$.1ashrop4xh1b.dlg@40tude.net> NNTP-Posting-Host: 85.3.246.240 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1218230734 19426 127.0.0.1 (8 Aug 2008 21:25:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 8 Aug 2008 21:25:34 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: x35g2000hsb.googlegroups.com; posting-host=85.3.246.240; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1570 Date: 2008-08-08T14:25:33-07:00 List-Id: 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. In such protocols the client is free to issue new requests whenever he likes and the server will dutifully *wait* for each of them. Telnet is one such protocol. HTTP is another (client can ask for the page and its dependent files like images via a single connection). CORBA (and virtually every other RPC-like middleware) uses it for handling many RPC requests from a single client. And so on - the list is endless. > 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. 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. > 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. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com