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,e8c6974546bc3f7f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.87.170 with SMTP id az10mr4199515wib.0.1354005648662; Tue, 27 Nov 2012 00:40:48 -0800 (PST) Path: ha8ni52017wib.1!nntp.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Sockets Example Sought Date: Tue, 27 Nov 2012 09:41:32 +0100 Organization: cbb software GmbH Message-ID: References: <2012112311175432190-rblove@airmailnet> <2012112315585358568-rblove@airmailnet> <17vopoh3g5mg4.jv11ioybge4k$.dlg@40tude.net> <2012112412270484092-rblove@airmailnet> <17btkxe7c0dse.1dndrk5qjz65x.dlg@40tude.net> <2012112621374336634-rblove@airmailnet> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-11-27T09:41:32+01:00 List-Id: On Mon, 26 Nov 2012 21:37:43 -0600, Robert Love wrote: > BTW, is there an official way to tell when the client closes the > socket? None of the transport's business, which TCP/IP is. > When I'm reading data, I can tell. If I'm not reading data, > I can call the Get_Peer(socket) function and catch an exception. It > just seems there should be another way? Normally there are multiple further layers mounted on the TCP/IP transport stream, up to the application level. These are usually stateful, and they may have states corresponding to a desire to disconnect, on either side depending on the roles the sides play. [Provided, that the protocol is connection-oriented. There are protocols which are not connection-oriented, even though using TCP/IP as the transport. For them whether the other side is gone might be just irrelevant.] Of course ether side must be prepared to anticipate protocol errors and connection loss is just one of them. Connection-oriented protocols usually have corresponding states for this, In such a state the participants would roll back, one of them would try to restore connection etc. The bottom line is, usually you would not care actively checking it. Once you experience an error you react correspondingly. [Keep-alive issues is another story.] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de