On Thu, 4 Mar 2004, Shachar Shemesh wrote:
That is not the case here. TCP/IP assumes that packets do not get
corrupted along the way(1). It therefor assumes that, if a packet is
lost, it's beause of congestion. As such, the rate at which ACKs arrive
is tightly bound into the TCP/IP rate
i am looking for a file-transfer program (for linux), which can run one
upload and one download simultaneously, on a _single_ TCP connection (sort
of the TCP equivalent of the BModem protocol used on BBS-es years ago).
i assume this will need to be a client+server application (since standard
I don't know any client that does what you said
but maybe udp one would solve your problem as well?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Thu, 4 Mar 2004, guy keren wrote:
i am looking for a file-transfer program (for linux), which can run one
upload and one download
On Thu, 4 Mar 2004, Eran Tromer wrote:
Questionable motivation aside, you can use ssh -L or -R to multiplex
several virtual TCP connections on a single physical TCP connection, and
run some file transfer protocol on each.
i thought about this, but:
1. ssh does encryption which adds overhead
On Thu, 4 Mar 2004, Ely Levy wrote:
I don't know any client that does what you said
but maybe udp one would solve your problem as well?
not likely, since an udp file-transfer program would have to implement its
own acks, which will bring me back to the same problem (i.e. acks will be
delayed
On Thu, 4 Mar 2004, guy keren wrote:
i am looking for a file-transfer program (for linux), which can run one
upload and one download simultaneously, on a _single_ TCP connection (sort
of the TCP equivalent of the BModem protocol used on BBS-es years ago).
i assume this will need to be a
guy keren wrote:
On Thu, 4 Mar 2004, Eran Tromer wrote:
Questionable motivation aside, you can use ssh -L or -R to multiplex
several virtual TCP connections on a single physical TCP connection, and
run some file transfer protocol on each.
i thought about this, but:
1. ssh does
guy keren wrote:
i am looking for a file-transfer program (for linux), which can run one
upload and one download simultaneously, on a _single_ TCP connection (sort
of the TCP equivalent of the BModem protocol used on BBS-es years ago).
i assume this will need to be a client+server application
Shlomi Loubaton wrote:
In many cases I discovered to my surprise that ssh performance were
better
comparing to other protocols. it seem that it uses data compression methods
and it's also configurable.
It's not just seems, see -C switch.
On the other hand, someone at my office just noticed
On Thu, Mar 04, 2004 at 12:22:56PM +0200, guy keren wrote:
i am looking for a file-transfer program (for linux), which can run one
upload and one download simultaneously, on a _single_ TCP connection (sort
of the TCP equivalent of the BModem protocol used on BBS-es years ago).
i assume
On Thu, Mar 04, 2004 at 04:50:33PM +0200, [EMAIL PROTECTED] wrote:
Shlomi Loubaton wrote:
In many cases I discovered to my surprise that ssh performance were
better
comparing to other protocols. it seem that it uses data compression
methods and it's also configurable.
It's not
Omer Zak wrote:
On Thu, 4 Mar 2004, guy keren wrote:
by the way, you might ask what's wrong with using two seperate TCP
connections - one for upload and one for download?. think of a slow link,
where a mass download in one direction slows down the ACKs for the upload,
and vice versa, giving
Shachar Shemesh wrote:
Omer Zak wrote:
How about adjusting TCP send and receive buffers to allow the
transmitter
to send several packets before waiting for the first ACK (assuming that
the link does not require too many resends)?
That aside, there is a TCP option called Delayed ACK, but it
13 matches
Mail list logo
