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

[Nicolas George]

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.

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

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

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://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110206/ade45ed0/attachment.pgp>