> Can you clarify something? Is this supposed to be a > packet protocol or astream protocol? > I.e., if the reader is waiting for 100 octets, and the > writer sent 20then 30 then 40, will the reader get three > reads of 20, 30, 40 or asingle read of 20+30+40=90?
This is a packet protocol. In your example above, the reader will get three reads of 20, 30 and 40 Sergio On Mon, 2021-02-01 at 15:22 +0100, Nicolas George wrote: > Sergio M. Ammirata, Ph.D. (12021-01-31): > For writing, the data you give librist, will go out "as > is"to the network with some added protocol overhead bytes > (28bytes without encryption enabled and 36 bytes > withencryption enabled). > Can you clarify something? Is this supposed to be a > packet protocol or astream protocol? > I.e., if the reader is waiting for 100 octets, and the > writer sent 20then 30 then 40, will the reader get three > reads of 20, 30, 40 or asingle read of 20+30+40=90? > To avoid your data being fragmented because of network > MTU,you should really limit the write size to what you > wantyour IP packets to be. For mpegts, for example, 1316 > is agood number to keep the overall packet size below > thetypical internet MTU size of 1500 (1400 to be safe). > It looks to me like reinventing the wheel that TCP had > had years to makenicely round. Do we need to implement > the Nagle algorithm? > Regards, > > _______________________________________________ffmpeg- > devel mailing listffmpeg-de...@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > To unsubscribe, visit link above, or > emailffmpeg-devel-requ...@ffmpeg.org with subject > "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
