Re: does putty use non-blocking sockets?
- From: Simon Tatham <anakin@xxxxxxxxx>
- Date: 15 Sep 2009 08:24:27 +0100 (BST)
yawnmoth <terra1024@xxxxxxxxx> wrote:
In my own SSH implementation, uploads are done at half the speed of
downloads. This is especially odd given that AES encrypts (which is
what it'd mostly be doing when uploading) twice as fast as it decrypts
(ie. as it downloads).
What on earth are you talking about? My implementation of AES goes
exactly as fast one way as the other, and I just refreshed my memory
of the AES algorithm and can't see anything in the spec that
suggests such a speed imbalance. Where do you get that figure from?
The reason why it does this is because, for whatever reason, the
socket blocks longer when writing than it does when reading. I was
thinking that one way to work around this would be to use non-blocking
sockets. ie. write one packet before the last packet has been
completely written. Is this what PuTTY (which doesn't have any
slowdowns like this) does?
I think you may have completely misunderstood. Non-blocking sockets
are an implementation detail which permit a program to carry on
doing computation while waiting for a time-dependent OS resource to
become available. Unless you had a _lot_ of computation you needed
to do while waiting, which in this case I doubt, they won't be the
cause of a factor of two speed difference in SFTP: they may have
performance implications one way or the other in terms of a few
system calls cost or saved, but that won't materially affect the
speed of a network transfer, because it'll be negligible compared to
the network bandwidth and latency.
More likely, the reason why your SFTP implementation is slower on
upload than on download is because upload is where an implementation
has the opportunity to optimise network usage in the face of
latency. What is your strategy for queueing FXP_WRITE messages? Do
you just send one, wait for the reply, and then send another?
One thing I worry about, with this, is... could the servers internal
buffer get full and start silently dropping packets?
No, don't worry about that. Network stacks are carefully designed
not to do that. Every OS software layer at both ends of a network
connection will keep the next layer along fully aware of how much
buffer space it still has available, so that nobody sends more data
at any time than the next layer is prepared to cope with.
The practical upshot is that if you try to send data when too much
data is already buffered, your send() or write() call will block, or
if you're using nonblocking sockets it will instead return
EWOULDBLOCK or EAGAIN (depending on local fashion) to alert you that
all the buffers are full and you should try again later.
--
Simon Tatham "That all men should be brothers is a
<anakin@xxxxxxxxx> dream of people who have no brothers."
.
- Follow-Ups:
- Re: does putty use non-blocking sockets?
- From: yawnmoth
- Re: does putty use non-blocking sockets?
- References:
- does putty use non-blocking sockets?
- From: yawnmoth
- does putty use non-blocking sockets?
- Prev by Date: does putty use non-blocking sockets?
- Next by Date: Re: does putty use non-blocking sockets?
- Previous by thread: does putty use non-blocking sockets?
- Next by thread: Re: does putty use non-blocking sockets?
- Index(es):
Relevant Pages
|
