Theads and FTP

[Roedy Green]

I have watched FTP voyager work. It seems to have at least two threads
simultaneously uploading downloading. You might think what's the
point. You can be transferring while you are waiting for the server
to open or close a file and send back confirmation.

I was wondering if this is done by logging on twice and having two
completely independent sessions, or if FTP itself has some multithread
ability.
--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Daniel Pitts]

I have watched FTP voyager work. It seems to have at least two threads
simultaneously uploading downloading. You might think what's the
point. You can be transferring while you are waiting for the server
to open or close a file and send back confirmation.

I was wondering if this is done by logging on twice and having two
completely independent sessions, or if FTP itself has some multithread
ability.

Why not look up the RFC on the FTP protocol?

I seem to recall that it inherently uses two sockets, one for the
commands and one for transfers. I don't know if the command stream is
allowed (or expected) to be active during a transfer, I haven't read the
spec myself in quite a while.

Also, you don't necessarily need multiple threads to handle multiple
connections. In posix c "select()" is use to manage multiple connections.

HTH,
Daniel.

 

[Arne Vajhøj]

I have watched FTP voyager work. It seems to have at least two threads
simultaneously uploading downloading. You might think what's the
point. You can be transferring while you are waiting for the server
to open or close a file and send back confirmation.

I was wondering if this is done by logging on twice and having two
completely independent sessions, or if FTP itself has some multithread
ability.

Protocols are not multithreaded - apps that implement protocols can be.

Whether that particular FTP program uses 1 control connection (1 login)
and N data connctions or N control connections (N logins) and N data
connections is impossible to say based on the information that
you have posted.

Arne

 

[Arne Vajhøj]

Why not look up the RFC on the FTP protocol?

I seem to recall that it inherently uses two sockets, one for the
commands and one for transfers. I don't know if the command stream is
allowed (or expected) to be active during a transfer, I haven't read the
spec myself in quite a while.

Also, you don't necessarily need multiple threads to handle multiple
connections. In posix c "select()" is use to manage multiple connections.

I believe it is possible to write a FTP client single threaded even
without select.

Arne

 

[Roedy Green]

Why not look up the RFC on the FTP protocol?

Because they are written to impress rather than inform. It is far too
easy to misinterpret them.

Sometimes there is some catch why in theory you can do something but
not in practice. You have to learn that from someone who has used the
tool, not from the author.

--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Andreas Leitgeb]

I believe it is possible to write a FTP client single threaded even
without select.

Ok there's of course also poll(), and one could set all channels to
non-blocking mode and do a more or less(with sleep) busy loop iterating
through all the channels and see which of them have data...

Did you mean one of these, or was it a serious statement?

 

[Daniel Pitts]

Because they are written to impress rather than inform. It is far too
easy to misinterpret them.

Sometimes there is some catch why in theory you can do something but
not in practice. You have to learn that from someone who has used the
tool, not from the author.

Do you feel the same way about the JLS? My preferred approach is to read
the canonical spec, and then ask questions about what a particular
paragraph means if I can't understand it.

 

[Joshua Cranmer]

Because they are written to impress rather than inform. It is far too
easy to misinterpret them.

Most RFCs written nowadays are written with the mindset of detailing a
protocol specification, and often include things like discussion on
security impacts, i18n concerns, etc. Any modern RFC is pretty good
about detailing how the protocol looks, although there are certainly
cases where the real world doesn't agree with the RFC (e.g., active FTP
frequently runs afoul of firewalls in practice, and the use of text
transfers is questionable in practice). For the most important old
protocols, there is often a large number of newer RFCs that update them
with better support for security and i18n concerns.

It also has been my experience as a major consumer of RFCs that the
question of misinterpretation is not so much a result of RFC text being
wrong but how to deal with idiot software that puts literal crap on the
network in violation of RFCs--a casualty of server software playing the
"be liberal in what you accept" game and accepting many things in pretty
gross violation of the legal specifications, which people come to rely on.

And lest you think that it's merely a case of "I'm not looking at the
right RFCs", my experience comes heavily from an email/newsgroup
background, so I wager that the RFCs I have to work with are probably
among the most-heavily violated RFCs in existence.

 

[Arne Vajhøj]

Because they are written to impress rather than inform. It is far too
easy to misinterpret them.

Sometimes there is some catch why in theory you can do something but
not in practice. You have to learn that from someone who has used the
tool, not from the author.

I would think most FTP clients and servers are written based
on the RFC, so ...

Arne

 

[Arne Vajhøj]

Ok there's of course also poll(), and one could set all channels to
non-blocking mode and do a more or less(with sleep) busy loop iterating
through all the channels and see which of them have data...

Did you mean one of these, or was it a serious statement?

Serious.

At least for some simple FTP client cases I believe it is
possible for the app to know what connection to read from
when.

Arne

 

[Joshua Cranmer]

It also has been my experience as a major consumer of RFCs that the
question of misinterpretation is not so much a result of RFC text being
wrong but how to deal with idiot software that puts literal crap on the
network in violation of RFCs--a casualty of server software playing the
"be liberal in what you accept" game and accepting many things in pretty
gross violation of the legal specifications, which people come to rely on.

To add as an addendum, it has never been my experience that fundamental
methodologies of an RFC (or any reasonable specification, for that
matter) are misinterpreted. In the case of FTP, it is constructed with a
main control connection, which sets up ancillary connections to actually
transfer data instead of doing it in the control connection; this is in
contradistinction to, say, IMAP, where messages are transferred inline
in the same connection as the control management.

Misinterpreting this much would be much the same as someone reading the
JLS and claiming that |int x = "I am a string!";| is legal Java code.

 

[Tom Anderson]

Serious.

At least for some simple FTP client cases I believe it is possible for
the app to know what connection to read from when.

Agreed. I am not aware of any requirement for either end to do anything to
the control connection while a transfer is in progress, and while a
transfer is not in progress, if there is a data connection, there is
nothing that needs to be done to it.

tom

 

[Tom Anderson]

Because they are written to impress rather than inform. It is far too
easy to misinterpret them.

What? The RFCs are some of the clearest, most straightforward, and least
pretentious specs i have ever read. They beat seven bells out of any of
Java spec after the JLS.

Well, up until the 2500-2800 period, anyway. They started to go downhill
around then. The modern ones are pap. I mean, look at this sad specimen:

http://www.rfc-editor.org/rfc/rfc6457.txt

in which we find such morsels as:

Also, note that an ingress LSR of a higher-layer or lower-layer LSP
may be present in multiple layers. Thus, even when a mono-layer path
is requested or supplied, PCEP MUST be able to indicate the
required/provided path layer.

Junk.

tom