[Icecast] Use of TCP_CORK instead of TCP_NODELAY

[Michael Smith]

>
> p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent
> article: http://www.baus.net/on-tcp_cork

Thanks for this pointer. I'd been meaning to reply on this thread, but
hadn't got around to it, primarily because I didn't really understand
TCP_CORK (the linux manpage is, as usual, fairly unclear on what
exactly it does). Now I understand!

>
> -----Oorspronkelijk bericht-----
> Van: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org]Namens Henri
> Zikken
> Verzonden: zondag 25 december 2005 15:05
> Aan: icecast at xiph.org
> Onderwerp: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
>
>
> We're abusing icecast in a true narrowcasting setup (personalized stream per
> mountpoint). The streams itself are created in a piece of proprietory
> (spelling?, i'm dutch) software, icecast merely relays them.
>
> However, the intended endpoint is an embedded device. This device has
> trouble with tcp/ip packets not matching the max. packet size (MSS or MSS
> minus header). After eleborate testing, we found that using the sockopt
> 'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on the field
> on reconnects etc/. Also, with streaming media, TCP_CORK is more efficient
> than TCP_NODELAY.

This is pretty broken. There are really three possibilities. In order
of increasing maximum delay:
  1) TCP_NODELAY - what icecast uses, deliberately.
  2) default (Nagle) - we used to do this in icecast.
  3) TCP_CORK - what you've added

As a streaming server, it's fairly crucial for icecast to send out
data with as low a delay as possible (many clients don't care, but
some do). That's why we use TCP_NODELAY - we actually WANT to send out
data as soon as we can.

There are limits to how much overhead is reasonable to accept, which
is why we do some aggregation in userspace; this aggregation should
probably be tuned better, but it's important that icecast control it,
not the kernel.

You want TCP_CORK, it seems, because of bugs in your target devices -
well, whilst we're willing to make some concessions to broken clients,
an inability to speak TCP correctly is well outside what I consider
sensible, particularly given that it will degrade icecast's
performance for working clients (you remain welcome, of course, to
hack up your local copy). It's also very unportable.

Mike