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

[Lukasz M]

> Non-blocking operations in lavf are completely distinct from the interrupt
> callback stuff. You get non-blocking operation by setting the
> AVIO_FLAG_NONBLOCK, and you get notified of a blocking operation by
> AVERROR(EAGAIN), this was already stated in this thread.
>
> If the FTP code uses the interrupt callback to implement non-blocking reads,
> it is misusing it and should be fixed. A quick glance at the code seems to
> indicate that this is indeed the case. A clarification in the doxygen
> comments may help other people not doing the mistake twice.

Thanks for confimation that is bug. I will fix it soon. I will try to
update doxy a bit too.
Current doxy and logic inside network waiting function might suggest it


>> It is good to use ffmpeg's implementation to be sure it is portable.
>> One of these connections is a "control connection" where you
>> communicate with the server on Request - Response basics.
>> Requests and Responses are line of text (human readable).
>> Responses from the server may be asynchonous, and may be multilined.
>> when you get response you may want to read socket again to be sure
>> there is no data left you want to precess as a result of previous
>> Request. (for example response was larger then your read buffer). When
>> you don't do that there is a chance this unread line will affect next
>> Request's Response. When you read in blocking mode then everything
>> freeze where there was nothing else.
>
> What you write here surprises me very much. I have never delved into the FTP
> protocol itself, but I have studied other protocols designed by the same
> people in the same era, and they all are completely synchronous and
> delimited, and therefore suitable for use in blocking mode.

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)
Ohter case is when file transimission is finished, you ge at
notification on control connection without sending any command.

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. So far I misused
this interrupt callback for this, but polling a socket also solve
this/

Maybe "asynchronous" it too strong word for this behaviour, I hope I
get more clear myself now.

> If FTP is not so, I would very much like to see somewhere explaining it in
> details, or at least pointers to the problematic part of the protocol.

See above

> Otherwise, the most obvious option would be to try to get FTP working in
> purely blocking mode (IMHO there is no point in trying to get FTP working in
> non-blocking mode while HTTP still can not).

OK, I hope you understand minor limitation of FTP implemntation in
ffmpeg, but it is blocking in general.
This "non blocking operations" regard only these extra responses I mentioned.
>From upper level (client of ftp protocol in ffmpeg) see read, write,
seek operations blocking.

Best Regards,
Lukasz Marek