From libssh2-devel-bounces@cool.haxx.se Mon Nov 16 03:24:26 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AG2NjTt014589; Mon, 16 Nov 2020 03:24:15 +0100 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20:0:0:0:d2f]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AG2Ngmb014568 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 16 Nov 2020 03:23:43 +0100 Received: by mail-io1-xd2f.google.com with SMTP id m9so15713610iox.10 for ; Sun, 15 Nov 2020 18:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EpLfMb058XJDrg1LhFnZou5905hGRT84r0rABa3VPdc=; b=tOtolbzT41PPHoz99o2fESSuUoMinvcXfGPRBMgbly+ZOmFW+m3yrvQ1PXJ/ReCUxA M0GOwfl/0i1N0ml061y9KOlVk7GW3LcYL4/bd/J9sRpnJjLDgl593lNo4TikMriR8baQ K6sk1TH7fe6MfrsL3XNXox1kuKY4PsnxgHIn3X5DXA8FgzWQ7TpFawHp+sJk/f01Cajh 93kt0+mIhIMPyo8JQu5qN6VEeJYONUCBrlgvOF4PBQjAo5t/ZFFmqa6dWcgURdMaI2dt 2Mo+2cmGlftS6SFLLB8Ixwg/+dBTBkzkUCP+bU2W67qdjxE1bArXkSbRDH95uF9XUED5 Ltlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EpLfMb058XJDrg1LhFnZou5905hGRT84r0rABa3VPdc=; b=KO9q+WngBzbaDFcJmSmv9h7+2NS569QB54S3m/83DPeqjqDV2pI2vGDpWe1/LEiEr4 aoOp8ECqD+AdEAGG1QhngW5tThUghV7/NCu4ApyfescVplielJAC+BrCHlsj7ldv89xc 0X4E3w31qN24c4vCG4HK9aB468VnMgaUMr8FATELL6qmCbsN7Cf43SI9XZ4jG+Zwm0cm 4XYJwCnamWaEtxcxa3Qma9T7WtEwSTknFJOGdb5WShn/LfG/CcaLSq3m3eC0J3cyzU7H puozKUuUag7w1fcdNTqBAkzUBxNIaidrQkXuTJrxkRzVcoxKtdaekCh4bK2gurwgYcdU NVBA== X-Gm-Message-State: AOAM533nqXYx3Ykp3yWdbEcSr6muB075jgeJ8vy5cFt+Njoi1IIrtJ15 JANeh9/94w5SqF7rMvVAGRF+qI3GX/ytPhrLlZLfUpqL29Y= X-Google-Smtp-Source: ABdhPJyYCBNFGANb31+nBfu5alL+DgWndgz/4oHuloWN8sCu1RLNEZGwSasmkO9omeelkdRhQZggULeBh/fdbgaO7kE= X-Received: by 2002:a6b:8e0d:: with SMTP id q13mr6525915iod.82.1605493418754; Sun, 15 Nov 2020 18:23:38 -0800 (PST) MIME-Version: 1.0 From: Jason Ni Date: Mon, 16 Nov 2020 10:23:29 +0800 Message-ID: Subject: Re: Multiple channels and epoll(7) To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1485816677==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1485816677== Content-Type: multipart/alternative; boundary="000000000000ea0c9c05b4301039" --000000000000ea0c9c05b4301039 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear folks, I was trying to use async-ssh2, which is an async wrapper of libssh2, to implement a remote port forward proxy. However, I may encounter the same issue as talked in this thread 6 years before. Could any one help to confirm that is there any rework or fix of this issue= ? Thanks a lot! Best regards, Jason Ni ---------------------------------------------------------------------------= ------------------------- From: Henrik Nordstr=C3=B6m > Date: Fri, 27 Jun 2014 11:19:11 +0200 tor 2014-06-26 klockan 23:24 -0600 skrev Eduardo Silva: *> but there is a remaining problem, when i get the notification that * *> some data is available, after try to accept a channel and then read * *> all channels, i need a timeout in the event loop to re-check if * *> something was pending. Still wondering how to avoid that re-check. * Looking at your code, and thinking and ugh... the libssh2 API is borked when it comes to handling of multiple concurrent channels. What I said earlier might work if you set epoll into edge triggered mode unless kernel cancels events if they get cleared before processed (I do not remember what happens, maybe kernel release dependent even). But current libssh2 API makes any level triggered non-blocking I/O on multiple channels unreliable (including poll/select) and requires a short timeout to avoid blocking due to incoming packets being held in the libssh2 packets queue without the application being aware. Looping over all channels until all report EAGAIN shortens the window where this may happen, but do not eleminate it as packets may still arrive into the packet queue while you process later channels. The earlier discussed API addition of giving access to inspect the packet queue would help solving this. You then loop processing until internal packet queue is drained. When internal packet queue is drained you know that libssh is actually waiting for the socket. Separating I/O from processing would also solve this problem and likely scale better with number of channels, removing the implicit socket read from libssh2_channel_read() and friends, requiring a explicit separate call to read the socket. Another interesting thought would be to aim to rework the libssh2 API to the level that it can support libevent buffered I/O events and similar I/O loops by delegating all actual I/O to the application. Above is likely a first step towards that. Regards Henrik --000000000000ea0c9c05b4301039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear folks,

I was trying to use async-ssh2, which is = an async wrapper of libssh2, to implement a remote port forward proxy.
=
However, I may encounter the same issue as talked in this thread = 6 years before.
Could any one help to confirm that is there a= ny rework or fix of this issue?

Thanks a lot!

= Best regards,
Jason Ni


-------------= ---------------------------------------------------------------------------= ------------
From: Henrik Nordstr=C3=B6m <henrik_at_henriknordstrom.net>
Date: Fri, 27 Jun 2014 11:19:11 +0200

tor 2014-06-26 klockan 23:24 -0600 skrev Eduardo Silva:

> but there is a remaining problem,= when i get the notification that
> some data is available, after try to acc= ept a channel and then read
> all channels, i need a timeout in the ev= ent loop to re-check if
> something was pending. Still wondering h= ow to avoid that re-check.

Looking at your code, and thinking and ugh... the libssh2 API is bor= ked
when it comes to handling of multiple concurrent channels.

What I said earlier might work if you set epoll into edge triggered = mode
unless kernel cancels events if they get cleared before processed (I do
not remember what happens, maybe kernel release dependent even). But
current libssh2 API makes any level triggered non-blocking I/O on
multiple channels unreliable (including poll/select) and requires a
short timeout to avoid blocking due to incoming packets being held in
the libssh2 packets queue without the application being aware.

Looping over all channels until all report EAGAIN shortens the windo= w
where this may happen, but do not eleminate it as packets may still
arrive into the packet queue while you process later channels.

The earlier discussed API addition of giving access to inspect the
packet queue would help solving this. You then loop processing until
internal packet queue is drained. When internal packet queue is drained
you know that libssh is actually waiting for the socket.

Separating I/O from processing would also solve this problem and lik= ely
scale better with number of channels, removing the implicit socket read
from libssh2_channel_read() and friends, requiring a explicit separate
call to read the socket.

Another interesting thought would be to aim to rework the libssh2 AP= I to
the level that it can support libevent buffered I/O events and similar
I/O loops by delegating all actual I/O to the application. Above is
likely a first step towards that.

Regards
Henrik

--000000000000ea0c9c05b4301039-- --===============1485816677== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwczovL2Nvb2wuaGF4eC5zZS9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbGlic3No Mi1kZXZlbAo= --===============1485816677==-- From libssh2-devel-bounces@cool.haxx.se Mon Nov 16 20:48:59 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AGJmSZK004202; Mon, 16 Nov 2020 20:48:50 +0100 Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AGJmOlD004178 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 16 Nov 2020 20:48:26 +0100 Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 0AGJmJgc021264 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 16 Nov 2020 11:48:19 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0AGJmJwc021263 for libssh2-devel@cool.haxx.se; Mon, 16 Nov 2020 11:48:19 -0800 (PST) (envelope-from jmg) Date: Mon, 16 Nov 2020 11:48:19 -0800 From: John-Mark Gurney To: libssh2 development Subject: Re: Multiple channels and epoll(7) Message-ID: <20201116194819.GP31099@funkthat.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 16 Nov 2020 11:48:19 -0800 (PST) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 0AGJmSZK004202 Jason Ni wrote this message on Mon, Nov 16, 2020 at 10:23 +0800: > I was trying to use async-ssh2, which is an async wrapper of libssh2, to > implement a remote port forward proxy. > However, I may encounter the same issue as talked in this thread 6 years > before. > Could any one help to confirm that is there any rework or fix of this issue? I'd like to see this as well... I'm running into an issue that in order to work around the api brokenness, that I end up busy waiting. This is because when opening a channel (new sftp connection), you can't tell if the EAGAIN is due to another channel receiving data, and needing to continue, or if it needs work to progress. > ---------------------------------------------------------------------------------------------------- > From: Henrik Nordström > > > Date: Fri, 27 Jun 2014 11:19:11 +0200 > > tor 2014-06-26 klockan 23:24 -0600 skrev Eduardo Silva: > > *> but there is a remaining problem, when i get the notification that * > *> some data is available, after try to accept a channel and then read * > *> all channels, i need a timeout in the event loop to re-check if * > *> something was pending. Still wondering how to avoid that re-check. * > > Looking at your code, and thinking and ugh... the libssh2 API is borked > when it comes to handling of multiple concurrent channels. > > What I said earlier might work if you set epoll into edge triggered mode > unless kernel cancels events if they get cleared before processed (I do > not remember what happens, maybe kernel release dependent even). But > current libssh2 API makes any level triggered non-blocking I/O on > multiple channels unreliable (including poll/select) and requires a > short timeout to avoid blocking due to incoming packets being held in > the libssh2 packets queue without the application being aware. > > Looping over all channels until all report EAGAIN shortens the window > where this may happen, but do not eleminate it as packets may still > arrive into the packet queue while you process later channels. > > The earlier discussed API addition of giving access to inspect the > packet queue would help solving this. You then loop processing until > internal packet queue is drained. When internal packet queue is drained > you know that libssh is actually waiting for the socket. > > Separating I/O from processing would also solve this problem and likely > scale better with number of channels, removing the implicit socket read > from libssh2_channel_read() and friends, requiring a explicit separate > call to read the socket. > > Another interesting thought would be to aim to rework the libssh2 API to > the level that it can support libevent buffered I/O events and similar > I/O loops by delegating all actual I/O to the application. Above is > likely a first step towards that. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Nov 16 22:12:01 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AGLBTY5022010; Mon, 16 Nov 2020 22:11:49 +0100 Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AGLBR5l021990 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 16 Nov 2020 22:11:28 +0100 Received: (qmail 21810 invoked by uid 1000); 16 Nov 2020 21:11:22 -0000 Message-ID: <20201116211122.21809.qmail@stuge.se> Date: Mon, 16 Nov 2020 21:11:22 +0000 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Multiple channels and epoll(7) References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 0AGLBTY5022010 Dear Jason, Jason Ni wrote: > I was trying to use async-ssh2, which is an async wrapper of libssh2, to > implement a remote port forward proxy. > However, I may encounter the same issue as talked in this thread 6 years > before. > Could any one help to confirm that is there any rework or fix of this issue? I don't think there has been any work to improve libssh2 in this regard. Sorry //Peter _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Nov 16 22:38:52 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AGLccuK027541; Mon, 16 Nov 2020 22:38:48 +0100 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20:0:0:0:333]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AGLcaqc027526 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 16 Nov 2020 22:38:37 +0100 Received: by mail-wm1-x333.google.com with SMTP id s13so837729wmh.4 for ; Mon, 16 Nov 2020 13:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=N5mTzZfFZ1IDxZWGnPhyQimUFRSzOEKSskw67tmE2r0=; b=Ai5rf7MzyTdlYIO16lcAfVgZynqIHkTcOy4fc+96pw9aLxziMlAr2DuM1Z9DRqs3bF vchhpIGTUUjGvR5Y7dAZVR/ImGugzEmTYhI285RD2DI+60V4xNPbuitH/jS5Ava8DGPD fHhmTxahvRlTeU/f1M5roG/q6xnGA8coxA1eQPwdJmqzGDUayw3sSTpYwpZHd8FM4qFU OHOeHJSoaJvXgOncmW1FHHSB0vCREuOBB1HWlmV0OGeUVXvbE9SQrVbJsrpBeVUEB2QL e/PDXXtGcl2qKarT94eZlSIFBQx/ZSP763tLlQ8zRzjBB/OB9fHP6A1PQzVuHqkZqoY1 TpOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N5mTzZfFZ1IDxZWGnPhyQimUFRSzOEKSskw67tmE2r0=; b=g2BWyDsZBRZn2xQ2L3sCuSUcESSYqACIpmXAfRCa1DIeRd0O2L3hnG1qGvZodvdZLI EQ/kvgwFVXFqO5pQ6oCciJ1SGJq06zlMsNoHHYE7LaVJWoxhRCSHP+rJsypA6TwsSe0S SVOn7SBAfjOYTqRFdF9VPctLvjgWkGCs3ViircaJqU+ag/6b2BxqTeJ3opAABv+2N9D4 MZtjAO9+QmvmqPiJrxZ9OojfgYJ4A7KjhM7iHF0+kklnfthqNCadTKrIY0y42vcqG09j kD14d7JHBiavtyBSxuJ1R+rBd71R2bqKXctD6xwIadavbn0yZnGDt7z1Ytg/XoMMlSl6 Vf6g== X-Gm-Message-State: AOAM530GRSUA+B6vSgtlxVrFgIyrfRWNEB6TnLE11JRUS3yHceJK9Tx9 kG7wLltKVVgum8YTPLN6H3xe0e9LF3jblDWtgh8k/yEgSw== X-Google-Smtp-Source: ABdhPJxKu77wZ+w1Kdt0fkJC33LEpmMpCHTUDNWxleN1/Uk8c8oGLg3LoKayBBMSUPmprlYpO2OFQts1Fe479sFZZLg= X-Received: by 2002:a1c:61d4:: with SMTP id v203mr878245wmb.1.1605562713456; Mon, 16 Nov 2020 13:38:33 -0800 (PST) MIME-Version: 1.0 References: <20201116211122.21809.qmail@stuge.se> In-Reply-To: <20201116211122.21809.qmail@stuge.se> From: Stef Bon Date: Mon, 16 Nov 2020 22:38:22 +0100 Message-ID: Subject: Re: Multiple channels and epoll(7) To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 0AGLccuK027541 Hi, I am not that familiar with libssh2, but is there a fd associated with every channel? Or is there a mutex/cond which are doing the signalling data is available? Only then you can do a per channel waiting/handling for io. Stef _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Nov 16 23:34:07 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AGMXddq007738; Mon, 16 Nov 2020 23:33:58 +0100 Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AGMXcVL007719 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 16 Nov 2020 23:33:38 +0100 Received: (qmail 22499 invoked by uid 1000); 16 Nov 2020 22:33:33 -0000 Message-ID: <20201116223333.22498.qmail@stuge.se> Date: Mon, 16 Nov 2020 22:33:33 +0000 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Multiple channels and epoll(7) References: <20201116211122.21809.qmail@stuge.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 0AGMXddq007738 Hi Stef, Stef Bon wrote: > I am not that familiar with libssh2, but is there a fd associated with > every channel? No. RFC 4254 chapter 5 describes SSH channels. They are just multiplexed byte streams within one SSH connection, described by RFC 4254. > Or is there a mutex/cond which are doing the signalling data is available? Also no. Both of these constructs are not very widely portable, so they're a poor fit for a cross-platform library such as libssh2. > Only then you can do a per channel waiting/handling for io. Well, every SSH connection runs over one TCP socket, and I think it would be possible for libssh2 to assist applications in I/O handling but noone has done it. At a minimum it requires a new state machine in libssh2, but getting it all done neatly would probably require rewriting much of libssh2... //Peter _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Nov 17 05:55:55 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AH4tFtB011088; Tue, 17 Nov 2020 05:55:41 +0100 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20:0:0:0:332]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AH4tCtV011060 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Nov 2020 05:55:12 +0100 Received: by mail-wm1-x332.google.com with SMTP id s13so2022816wmh.4 for ; Mon, 16 Nov 2020 20:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u1FGsZlaP3HephOUI7ETc0XZAthJI0pibEVVGNImJp0=; b=aynfvErdTelE9nGQTNFjvqI2st66LRt3yxTkr1FRZc/QP970Tpx+GYngGfxtHNjlbr 2nEo4W6VSG4yhzNf/zWb1vF3icdT+ExXBv1t64jqhI2gsw1gsKqprrsVCmESRqTjzO+T V+LrNjs86RXJovlGUyWMcmXjuReVr/SxuIuT6V3w+8kKiZEKosUNfwBTsyy0y4l9IA/V j4+gjYW3lcCC7sODS6Zh0TVH8ft82nVT6ifw020SQ69cZshNRg2N1snueMLzjSIw0dGn Ht+XD+ibZw3hCJTVjUAppMlux1dEwo1s/YlxDhLhrIWrDET4URZchZTuwHgDE5hz7shn b4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u1FGsZlaP3HephOUI7ETc0XZAthJI0pibEVVGNImJp0=; b=eq0qVva2AeHsk7IhdRHDZ+tnsda0YGkSWINkl5RMbKmlZuZfX7Bez0BguZtvONeU+7 PAQEC5L6je36rn9bxaX99x8tJ516SYQsri4Sa+U3theh6Sfz8t5GD/US6Lh3k96z99Ph awLr9SsWYVPc9wK84t9HteZ14F6B8+d4YHC8476nUQxix3iTK6ceWXq2jhQtf+hj7J9H ipbmCrzcVVD/EMPIjn0XCIRtxrhmsQJkl0KHf+ABRkkTOL8w6Nb4ICwjraPdqEKIflyL 3aAcsPDhf1bYsyBj+s6fw3QStTfWmJN5vGVstQT7Z6JnSgVWpJ+HeBPJ4qdg22jRRwj/ NIIA== X-Gm-Message-State: AOAM531/GQyo/qobivu6RrmS+Uw0kxSKQ4wjOQE2w1WoQdqgCnMXm9+O fYueMLypRiw+gaH4hx1q5gBaOmSV1QyVn8H/ZyI8tMNNDhum X-Google-Smtp-Source: ABdhPJwZofhtgCghfgp3p5I78Ze3U/TdPKQa3XBqqIGEhIShPX0+9hZq+zInCpdH9GCdMliE96u6VDmiRQ5XAv+0MWY= X-Received: by 2002:a05:600c:2202:: with SMTP id z2mr2273702wml.95.1605588907570; Mon, 16 Nov 2020 20:55:07 -0800 (PST) MIME-Version: 1.0 References: <20201116211122.21809.qmail@stuge.se> <20201116223333.22498.qmail@stuge.se> In-Reply-To: <20201116223333.22498.qmail@stuge.se> From: Stef Bon Date: Tue, 17 Nov 2020 05:54:56 +0100 Message-ID: Subject: Re: Multiple channels and epoll(7) To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 0AH4tFtB011088 Hi, Goodmorning. How do you do? I know the design of SSH and the connection protocol described in RFC 4254, and I know that by design only the ssh session has a fd. I'm working on a FUSE network filesystem service which connects to SSH servers in the network automatically, using Avahi to detect the hosts/services, and mounts on /run/network/$user, and offers there a browseable map to access the shared folders (at least the home directory) like: /run/network/sbon/bononline.nl/fileserver/home The sftp client uses a hash table to wait for a response (a thread is waiting some time after sending to wait for a response). Under the hood the response on the channel data message is first processed by the eventhandler, taken over by a separate thread to decrypt, then recognized as a channel data message, and the for that channel specific receive data function is called. When setting up a channel, this will queue it in a channel specific queue (for example the ssh channel open conformation message) for the waiting thread to finish the setup of a channel, for the sftp client (when channel is setup) this will analyze the channel payload (using https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 for sftp version 6 for example), and signal the waiting thread which started the request a response is there. Now all these io functions use one set of mutex and cond, to make it possible to react on all these events: - a response has arrived - no response causing a timeout - response the received packet is invalid - connection is closed/some error - channel is closed - ssh session is closed - original request (by FUSE) is interrupted To handle all these events well, one set of mutex/cond is used for the mount point and all the services like ssh connection, channel and sftp io. See for example the wait for a response function for sftp in: https://github.com/stefbon/fs-workspace/blob/master/sftp/request-hash.c#L352 I had to write my own ssh implementation cause no other library offers this integration with the context (FUSE) sharing the mutex/cond to signal for all kinds of io events, over multiple channels. Now like I said I do not know libssh2 that well. Stef _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Nov 17 16:15:30 2020 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 0AHFEsMb027393; Tue, 17 Nov 2020 16:15:19 +0100 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20:0:0:0:133]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 0AHFEpfS027376 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Nov 2020 16:14:52 +0100 Received: by mail-il1-x133.google.com with SMTP id n5so18880386ile.7 for ; Tue, 17 Nov 2020 07:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KpS/kDbOvS9Ule+rh7dJls2AprHNewkzKl9tgI4W0TE=; b=SIyG14u0OYv189m3szSTZqIO+UN2RNR6CDonQiFxO/L5la7TUfghbXaXFKES9YKqkb YJgDGvh0HMJViZDx15GNU8s9cbi5D3XDmtQXH6gJjQaDa7gTdxI5dxVBU+tjXqBFZaCd /tMVX/uHcdL0F06wnNKbOIDE9YBuG+Mdwk2K+sSTFGftPC+i2aB64T1Vs4IzAcOO//SW iOvTZ49AXioV9Xz06GOsaA9/MmmpfIBTqR4BY4bSs0AZdIzC/yaj/hMUbeFCKnQZ4IKr uTP7NlA4KnQmzwHu8RzW1QTXWm9cGxjiHa9lEV7953WUup5UAYgzsT9d9uXjQZH1CATM LLog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KpS/kDbOvS9Ule+rh7dJls2AprHNewkzKl9tgI4W0TE=; b=LFxMKZe1xs02t/eWJoZUTsiJHfuRSiR5p0cvJD+qh5wjRzhQailo+GcXLyMxKi5WdS 1V4qW0iFkt7weh6cm+1fYHQWUSNJ7SmKDVcYv+UH4ZTYbmjuaxr4SXBjD7AVp1NONoar 9z3c6pnFkmOPfog+dz92E62K93COC/1eBqFL0Q4DW+aFtVgb8VRsMpl6Rhmsb3m3dg0i INl0/twaz5IeeDB0sFSxalfkFm4HveTh6FvPJ3+mAU60OQxGqJXdVzHhdLoZeenMIbZt XZ5jcuKfVct8hH4nUlCu5ExnUuX3xhgQtXMN1GU9ZvAmpnh2HgCkog02lrQdaLyIbRnc YChA== X-Gm-Message-State: AOAM531Id8JvxoHSbNSh9qyP05puEQ0nN5AfzWpRbZmorbG3DhC3YnvG K+86R+6VEsNC8iGidU2c/CJ+e8Lk/XASMTELQ38a/rZmmgo= X-Google-Smtp-Source: ABdhPJz8CjhfAveJfpuBraRZd5JNTgJSg3ebhx7aFWFtGop8t4+TRp7aOUXS41EyX01HjWYhRyQQT6y0GFNZBI/Y21A= X-Received: by 2002:a92:6e0a:: with SMTP id j10mr12604698ilc.272.1605626086263; Tue, 17 Nov 2020 07:14:46 -0800 (PST) MIME-Version: 1.0 From: Jason Ni Date: Tue, 17 Nov 2020 23:14:35 +0800 Message-ID: Subject: Re: Multiple channels and epoll(7) To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0027303854==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0027303854== Content-Type: multipart/alternative; boundary="000000000000838fa805b44ef49f" --000000000000838fa805b44ef49f Content-Type: text/plain; charset="UTF-8" Dear Peter, Thanks for your confirmation. Sorry that I screwed up the mailing thread again. My gmail account just received the digest in one mail :( Best regards, Jason --000000000000838fa805b44ef49f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Peter,

Thanks for your = confirmation.

Sorry that I screwed up the mai= ling thread again. My gmail account just received the digest in one mail :(=

Best regards,

Jason
<= /div>
--000000000000838fa805b44ef49f-- --===============0027303854== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwczovL2Nvb2wuaGF4eC5zZS9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbGlic3No Mi1kZXZlbAo= --===============0027303854==--