[FFmpeg-devel] [PATCH 3/3] Non-blocking protocol: TCP

[Martin Storsjö]

On Sun, 6 Feb 2011, Nicolas George wrote:

> L'octidi 18 pluvi?se, an CCXIX, Martin Storsj? a ?crit?:
> > As Nicolas said, all of these read UDP packets. There, url_read() either 
> > returns one packet, or no data at all, there's nothing inbetween.
> 
> ... if the buffer is big enough (which seems the case here). If I remember
> correctly, recv on a UDP socket with a buffer smaller than the packet will,
> by default, truncate the packet to the size of the buffer and discard the
> rest.
> 
> This behaviour would be disastrous with code that expect a stream-like
> interface and use url_read_complete. Except that most of the time, the
> pseudo-stream would have been muxed and emitted the same way, which means
> that protocol packet boundaries will most of the time coincide with content
> packet boundaries. But not always.
> 
> I still thinking about it.

Yes, the buffers must be large enough. This is an orthogonal issue anyway, 
any such usecase that worked before won't be affected by this, as far as I 
can see.

> > Btw, it might be handy to be able to switch between blocking and 
> > nonblocking mode on URLContexts after creation, too.
> 
> Indeed. In fact, when protocols depends on other protocols (like HTTP
> depends on TCP), switching from blocking (for the header / connection) to
> non-blocking (for the payload) will be necessary.

True. Even worse cases are what to do for seeks (which in HTTP open a new 
connection) - making that operation nonblocking would be tricky, to say 
the least. I guess we'll have to do with blocking behavior for those 
parts. This patchset is a big step forwards anyway.

> >							As far as I can see 
> > from the patches, this wouldn't be much harder than adding a function that 
> > sets/clears that bit in h->flags.
> 
> That is currently true, and probably will stay true for the protocols I
> know. Still, the setting function is a better solution for long-term API
> stability.

Yes, a function sure is better, I just meant that it won't be hard to 
implement that function, in the current design.

// Martin