www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: [PATCH] Follow RFC4253 section 11.4

Re: [PATCH] Follow RFC4253 section 11.4

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Thu, 01 Mar 2012 23:08:46 +0100

tor 2012-03-01 klockan 22:39 +0100 skrev Peter Stuge:

> This
> might already be managed within libssh2 though, that keepalives are
> never sent in the middle of another request.

In blocking mode keepalives are by default sent in the middle of other
requests by _libssh2_wait_socket.

And applications is very likely to do use libss2_keepalive_send in
similar manner in non-blocking mode.

Also be warned that libssh2_keepalive_send corrupts transport if only
part of the keep-alive message can be sent.

> I don't think an SSH client can allow itself to send a global request
> with want reply = 0 if it is not already sure that the server
> supports that particular request, unless the client adds some
> elaborate buffering of global requests it has sent and tries to track
> which ones have been answered by the server. Not what we want.

You only need to track the sequence number of the pending packets you
currently expect a response to. Getting UNIMPLEMENTED as response to a
packet you are not expecting a response to can safely be ignored I
think.

It's not really about global requests as such. You may in theory see
UNIMPLEMENTED as response to any packet. In this specific case it's seen
because global channel requests (keep-alive) are sent before the
connection protocol is activated.

> I think want reply = 1 for keepalive would be fine, and isolates the
> problem to that part of the code.

Not really without also making keep-alives a round-trip blocking thing
preventing any concurrent unanswered packets of any kind during the
keep-alive probe, which I am sure is not fine.

Regards
Henrik

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-03-01

the libssh2 team