[FFmpeg-devel] [PATCH 3/5] ff_network_wait_fd_timeout(): check for interrupt before operation

[Lukasz M]

>> OK, In most cases it is synchronous. Each request gets response and it
>> synchronous.
>> Unfortunately, and this is implementation dependent, some servers send
>> extra responses and they may be delayed a bit (few second for example)
>> FFmpeg is not a regular client, and you cannot wait too long, and you
>> dont get any chance to handle it until next protocol API is called by
>> upper layer (read, write, seek function etc)
>
> Can you explain what these extra responses are?

I will come back with it, when I face it again. As I remeber one
server send transfer statistics (speed) with code 150.
I can't remeber details, I think it is handable without nonblocking
operation nor polls

>> Ohter case is when file transimission is finished, you ge at
>> notification on control connection without sending any command.
>
> As far as I can see, the notification for finished transmission is the
> closing of the data stream. That means the following workings should work:
>
>         Issue the RETR command.
>         Read the 150 status line on the control stream.
>         Read from the data stream until EOF.
>         Read the 226 status line on the control stream.
>
> Is there something I am missing?

No, but it is also not a problem to handle.

>> Regarding delimited responses. There is at least one response for each
>> command. Response is a line of text staring with code (3 digits)
>> terminated with new line character.
>> Simple example, right after you connect to ftp server you get 220 code
>> meaining server is ready. Usually 1 line, but you may get 50 when
>> admin set hello message containing 50 lines of text.
>> So you need to expect one response 220 to be sent, but it is worth to
>> consume all of them before sending next response.
>
> The protocol seems to allow to handle this kind of multi-line response
> correctly in blocking mode: multi-line responses are marked by a dash
> immediately after the three-digit code and terminated by a line with the
> (same) three-digit code followed by a space. Like that:
>
> 220-
>     Hello world.
>     This is a fine motd.
> 220 foobar FTP server.

I don't know it is misformatted by email servers etc, but usually 220-
would occure each line apart from last one that is without dash.

> Like all text-based protocols this is somewhat annoying to implement, but I
> believe ftp_status() can be rewritten to handle the multi-line responses
> that way and thus not having to rely on non-blocking operations and polling.
> Something like that:
>
>         Read first line.
>         Parse code and text.
>         if (dash) {
>             while (1) {
>                 Read next line.
>                 if (starts with code and space)
>                     break;
>                 Append line to response text.
>             }
>         }
>

Ok, I missed that dash markers. It solves that multiline issue.
It seems it can be done without non blocking read nor poll.

Thanks for help.
I prepare patch, submit soon.

Best Regards,
Lukasz Marek