From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: Re: How to notice abrupt tcp connection losses in server/client? Date: Fri, 22 Jun 2018 22:17:51 +0200 Message-ID: <965d5042-8d91-6729-e357-92cab60ca52b@gmail.com> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1529698590 22368 195.159.176.226 (22 Jun 2018 20:16:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2018 20:16:30 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jun 22 22:16:26 2018 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWSTp-0005hx-6a for guile-user@m.gmane.org; Fri, 22 Jun 2018 22:16:25 +0200 Original-Received: from localhost ([::1]:36015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWSVw-00066n-EE for guile-user@m.gmane.org; Fri, 22 Jun 2018 16:18:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWSVI-00064v-Re for guile-user@gnu.org; Fri, 22 Jun 2018 16:17:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWSVG-0006d9-W7 for guile-user@gnu.org; Fri, 22 Jun 2018 16:17:56 -0400 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:38110) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fWSVG-0006cP-LD for guile-user@gnu.org; Fri, 22 Jun 2018 16:17:54 -0400 Original-Received: by mail-wm0-x22c.google.com with SMTP id 69-v6so3894189wmf.3 for ; Fri, 22 Jun 2018 13:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=d18hhpRxGBWL7tlS1zFac7AWlCFA+Fl1uTyQcJ3ZFGY=; b=GsEL2l2F/qgKvOGHQlkBaWTCpdwSGRG2+TjWWqd0ZpCyeD0y3gwqWLvgSOlSWs7+17 GwjrbLCdyJk43ahaDYdSnypHJv4T212IM8lOuYfZCBKJftg/7o48+vF7g2FlW7qOF1Mx ntWH4E/V/LZFCnaJkjLCE1LI12C0y7eFl1Pfve4sXrGr/wFdPOfzN/B1Z3MHil1Z1g+Q phSqqHz0rQcE+Ve2AEEMFhMMPO6FoAlXVva1PbiuQBnjSkCwOYxnUAJTFqkYOBUexdv3 Jcs0cCbkYjT/IdCgu6B5gpCybqdVoGJXVkA4TOQHYnqurbALG4CKnaB9ui+aWsOwdO25 9+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=d18hhpRxGBWL7tlS1zFac7AWlCFA+Fl1uTyQcJ3ZFGY=; b=Kla9c3IAGLvfIyk92AWt5X/D1XoCBiiHXP81kc+YddHU00v/75Jjvuyr21DALzSYzM ECgxAcc7ONe+IbRWl5RMctaSRpwoJyPG5yIlOHwj5Y4HKVwGb/5PubUKLag+y8zMZP8O bmkhRBIqCPcqRP425LQ4HqHL2I0iuLtaz8sVNF+sBqJNlbFgFgbIdsprGUhq1gUt/R93 6D8Rg8UQiVcP/rULqacX2V/HpfWYotcUDmT4+Op3z3+PuIKWchr6zI2CzWc45sAp4WVv apX/5xMTXF5z0fGA2NstOtnG1W+bzQtMuX7DKx55EkgVQpzPiiAF8P17coR9vvLcaUlN ZM5A== X-Gm-Message-State: APt69E2lYpt+y/pjk9eG2SuT3qvvmZm6PfywX/ZE86hutQFPgqwYPHx9 a7XIk+moNx0DzppCCigm+hbEzA== X-Google-Smtp-Source: ADUXVKIchv+9xpw0jC/83m00JOin3U9WmfOBQ6Zsc6FHhXZDeioOveL530QRudfTh6oKZ9HVenfToA== X-Received: by 2002:a1c:c604:: with SMTP id w4-v6mr142991wmf.135.1529698673066; Fri, 22 Jun 2018 13:17:53 -0700 (PDT) Original-Received: from ?IPv6:2a02:8109:ad3f:ec78:24be:915b:25bb:93d3? ([2a02:8109:ad3f:ec78:24be:915b:25bb:93d3]) by smtp.googlemail.com with ESMTPSA id d102-v6sm3643754wma.10.2018.06.22.13.17.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 13:17:52 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22c X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:14650 Archived-At: On 22.06.2018 18:00, guile-user-request@gnu.org wrote: > Message: 2 > Date: Fri, 22 Jun 2018 00:09:16 +0100 > From: Chris Vine > To: guile-user@gnu.org > Subject: Re: How to notice abrupt tcp connection losses in > server/client? > Message-ID: <20180622000916.e5180d431446d15843d3f1e8@gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, 22 Jun 2018 00:19:49 +0200 > Zelphir Kaltstahl wrote: >> On 21.06.2018 18:00, guile-user-request@gnu.org wrote: >>> From: Chris Vine > [snip] >>> The POSIX recv() function returns 0 on end of file (connection closed) >>> so I expect the scheme recv! procedure does the same. So on end-of-file >>> your code appears to be producing an endless supply of empty strings. >> I actually tried to (break) the loop when the received message is >> (eof-object? ...), but it might be that I used this predicate at the >> wrong place (directly inside the loop when the message was already >> copied from the receive-buffer, instead of when recv!, I believe), now >> that I think about it ? and maybe that is why (break)ing the loop did >> not work. Need to investigate more. > It looks as if recv! returns 0 on end-of-file, not an eof-object, so > that may be your problem. That is not the case with get-line or > get-bytevector-n. Note that recv! may also return less than the > requested number of bytes - it does not guarantee to block until the > entire request has been met or end-of-file is reached, as it is just a > wrapper for POSIX/windows recv(). I think you are exactly right. If it returns 0 for end of file (what is the difference between this and end of file object?), then 0 bytes will be copied to the receive byte vector. When converting that to utf8 string, it will be the empty string and that is printed. However, since there is still no new message (client connection is no more) there is still only EOF and the same will happen over and over again. > I think you will need to use recv! with windows, because you cannot > read from sockets in windows using POSIX read(). With other OS's it > would be more normal to use the R5RS/R6RS port procedures, because they > are easier to use and are buffered. > > For asynchronous non-blocking ports, I am not sure whether recv! is safe > with guile-2.2's suspendable ports or not. The get-line and > get-bytevector-n procedures are. The get-bytevector-n! procedure is > not. I suspect recv! may not be also. > >>> More generally, you will find it easier to use something like the >>> get-line procedure to read text, or something like get-bytevector-n or >>> get-bytevector-n! for reading binary records. recv! only really becomes >>> important when the flags argument is meaningful. >> Ah ok, thanks for the advice! I thought recv! was the way to go, as it >> worked so nicely so far. > A call to unix read() on a socket is equivalent to a call to recv() > with default flags. At the end of it, the buffered guile port reading > procedures generally involve a call to read(). > >>> Rather than starting a new thread for each connection, you will get much >>> better scalability if you use something like fibers >>> ( https://github.com/wingo/fibers/ ), guile-a-sync2 >>> ( https://github.com/ChrisVine/guile-a-sync2/ ) or 8sync >>> ( https://www.gnu.org/software/8sync/ ). >> Yep =) I am aware. I already wrote a comment inside the code noting that >> this new thread thing is probably not so good. Not sure I should >> introduce fibers into this example code yet though. And looking at >> fibers and 8sync is on my to-do list ; ) >>> Chris >> I will try these things and see how it goes. Thanks! > The guile-a-sync/guile-a-sync2 libraries (of which I am the author) have > an example of a client and server in the doc directory, which might be > of interest to you. fibers is definitely worth a look also, but is > linux only, and also guile-2.2 only. I think it also has some examples > (not sure). > > Chris I now use get-bytevector-n with the count which was the size of the receive-buffer and it does not have the endless looping behavior. All seems fine now. Thanks!