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

Nicolas George nicolas.george at normalesup.org
Sat Jul 13 15:03:28 CEST 2013


Le quintidi 25 messidor, an CCXXI, Lukasz M a écrit :
> 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?

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

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

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

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/9432184e/attachment.asc>


More information about the ffmpeg-devel mailing list