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

[Nicolas George]

Le quartidi 24 messidor, an CCXXI, Lukasz M a écrit :
> I'm sorry if I wasn't clear.
> You can reffer libavformat/ftp.c file where FTP protocol is implemented.
> The case I have in mind is when you use TCP protocol to implement
> different protocol.
> In this example FTP protocol uses two TCP connections (this is a nature of
> FTP).

I have not yet had time to look closely at the whole patch series, but I
have a little knowledge in that area that I can share right now.

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.

Regarding non-blocking operation, it does not work, except for the lowest
level protocols. Fortunately, TCP _is_ a lowest level protocol, and AFAIK
non-blocking mode works fine for it.

[ digression about non-blocking mode for higher-level protocols ]

For higher-level protocols, it does not work because the implementations
will frequently read a whole field into a local variable, and possibly
continue reading according to the value (something like "length =
read_int16(); read(buf, length);"): if reading blocks between the two bytes
of the length, or between the length and the data, it will completely fail.

Protocols in write mode are even worse; demuxers have the same kind of
problem but an order of magnitude more because they are more complex; muxers
cumulate the problems.

Getting all higher-level protocols to work in non-blocking mode would
probably amount to a full task for each protocol.

A more generic solution would probably to run higher-level protocols and
demuxers in a separate user context, and switch back to the main context if
the underlying low-level protocol blocks.

[ end of digression ]

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

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.

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

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130713/f84281c9/attachment.asc>