Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10480 > unrolled thread

Theads and FTP

Back to article view | Back to comp.lang.java.programmer

Contents

  Theads and FTP Roedy Green <see_website@mindprod.com.invalid> - 2011-12-03 20:31 -0800
    Re: Theads and FTP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-04 13:14 -0800
      Re: Theads and FTP Arne Vajhøj <arne@vajhoej.dk> - 2011-12-04 22:06 -0500
        Re: Theads and FTP Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-05 14:58 +0000
          Re: Theads and FTP Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:01 -0500
            Re: Theads and FTP Tom Anderson <twic@urchin.earth.li> - 2011-12-06 21:07 +0000
      Re: Theads and FTP Roedy Green <see_website@mindprod.com.invalid> - 2011-12-05 05:33 -0800
        Re: Theads and FTP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-05 09:29 -0800
        Re: Theads and FTP Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-05 12:29 -0600
          Re: Theads and FTP Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-06 11:28 -0600
        Re: Theads and FTP Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:00 -0500
        Re: Theads and FTP Tom Anderson <twic@urchin.earth.li> - 2011-12-06 22:16 +0000
    Re: Theads and FTP Arne Vajhøj <arne@vajhoej.dk> - 2011-12-04 22:04 -0500

#10480 — Theads and FTP

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.
 

[toc] | [next] | [standalone]

#10495

On 12/3/11 8:31 PM, Roedy Green wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#10511

On 12/4/2011 4:14 PM, Daniel Pitts wrote:
> On 12/3/11 8:31 PM, Roedy Green wrote:
>> 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.

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

Arne

[toc] | [prev] | [next] | [standalone]

#10526

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/4/2011 4:14 PM, Daniel Pitts wrote:
>> On 12/3/11 8:31 PM, Roedy Green wrote:
>>> 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.

> 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?

[toc] | [prev] | [next] | [standalone]

#10539

On 12/5/2011 9:58 AM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 12/4/2011 4:14 PM, Daniel Pitts wrote:
>>> On 12/3/11 8:31 PM, Roedy Green wrote:
>>>> 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.
>
>> 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?

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

[toc] | [prev] | [next] | [standalone]

#10568

[Multipart message — attachments visible in raw view] — view raw

On Mon, 5 Dec 2011, Arne Vajhøj wrote:

> On 12/5/2011 9:58 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>>> On 12/4/2011 4:14 PM, Daniel Pitts wrote:
>>>> On 12/3/11 8:31 PM, Roedy Green wrote:
>>>>> 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.
>> 
>>> 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?
>
> 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

-- 
LEDERHOSEN IS NOT EDIBLE

[toc] | [prev] | [next] | [standalone]

#10524

On Sun, 04 Dec 2011 13:14:21 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>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.
 

[toc] | [prev] | [next] | [standalone]

#10531

On 12/5/11 5:33 AM, Roedy Green wrote:
> On Sun, 04 Dec 2011 13:14:21 -0800, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote, quoted or indirectly
> quoted someone who said :
>
>> 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.
>
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.

[toc] | [prev] | [next] | [standalone]

#10532

On 12/5/2011 7:33 AM, Roedy Green wrote:
> On Sun, 04 Dec 2011 13:14:21 -0800, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote, quoted or indirectly
> quoted someone who said :
>
>> 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.

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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#10564

On 12/5/2011 12:29 PM, Joshua Cranmer wrote:
> 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#10538

On 12/5/2011 8:33 AM, Roedy Green wrote:
> On Sun, 04 Dec 2011 13:14:21 -0800, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote, quoted or indirectly
> quoted someone who said :
>
>> 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.

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

Arne

[toc] | [prev] | [next] | [standalone]

#10574

On Mon, 5 Dec 2011, Roedy Green wrote:

> On Sun, 04 Dec 2011 13:14:21 -0800, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
> quoted someone who said :
>
>> 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.

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

-- 
I'd better quit my talking, 'cause I told you all I know. But please
remember, pardner, wherever you may go: the people are building a peaceful
world, and when the job is done, that'll be the biggest thing that man
has ever done.

[toc] | [prev] | [next] | [standalone]

#10510

On 12/3/2011 11:31 PM, Roedy Green wrote:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web