replies 150 and 226 on ls come together

[anonymous]

Just a thought
I am not claiming to be an expert on this.

The replies to ls
150 and 226 come together on the same
server reply. the client has to dig in there
to find out that those are actually to responses.

I thought it was confusing to the client side
it was in my client (my program), nothing
I could not handle though. I just though it
might be confusing to other clients.

I read the RFC959 and it is not clear
whether you should send them seperatelly

[Tim Kosse]

The replies to ls
150 and 226 come together on the same
server reply

That's not true. When you send LIST (ls), the server send
the 150 reply code and tries to open the data channel. If
it succeeds, it sends the directory listing and then sends
the 226 reply.
When the listing is very small or the connection very fast,
the server sends the 150 and 226 with a very small amount
of time between them.
Due to the nature of underlying network protocol (TCP/IP),
boths replies may arrive almost simultaniesly and the tcp
stack of the client may combine both, so that when you
recieve all data from the control socket, it could be
possible to read both the 150 as well as the 226 reply at
once.
The other way could be possible, too: A reply get's split
up in several parts on its way to the client, although this
should be extremely rare.
According to RFC 959, command and replies have to and with
a CRLF pair. Don't ever expect that you receive data
exactly in the same intervals as the server sends them. So
you need a buffer to hold the recieved data and search for
complete replies.