On 19/02/02 03:06, Jack Moffitt shaped the electrons to say:> > The point is, is this list related to icecast2 development? I made some > > changes to the server and sent a patch to Jack Moffitt, but I'm not sure > > he's still mainaining the server. > > You're in the right place, and I still maintain the server. I don't > remember your patch right off-hand but I'm going to look for it now.Just in case, I copy the mail and attach the patch. I am working in my second version (not included in the patch), I would like to hear some comments: - prebuffering parameter (used in previous patch) in now configurable in <limits>...<prebuffer>seconds</prebuffer>... - instead of disconnecting when the client-queue > 25, I discard packages wich are older than prebuffer*2. All clients I tried have recovered very well, even with a ping -f running behind. Regards, ------------ Dear Jack, find attached a patch that improves a lot the performance and reliability in the server. Specifically, I started the modifications due to the unreliability of the connection (mainly due to the lack of control in the nonblocking socket) when the client pipe was saturated, even for few seconds, for exaple due to a web page download. The problems tackled by this patch are: 1. The server didn't check for the status of the client's socket before the unblocking send(). This caused a disconnection at the minimum delay in the network. I've added a poll in sock.c 2. Many vorbis players do a very bad job in prebuffering (notably freeamp), so we are forcing a kind of prebufering now. The server keeps the last seconds of each source, when a new client connects, we send these previous buffers as fast as the network allows (this is checked by -1-). To allow the control by seconds instead of time, I added a timestamp to refbuf (which could be also used by checking the client queue length by seconds). 3. Solved a bug in source.c, when checking for recoverable error. It has to be done _only_ when result < 0. 4. Created a new function (send_client_queue) to send the client->queue. Better modularisation. 5. When a new client is added, we send the metadata right after adding it to the queue (I use the previous function). This improve a lot startup time inthe client. 6. Moved queue_lenght verification to the send_client_queue(). It doesn't make sense to do it if there is no pending buffers. 7. Added TCP_NODELAY to a nonblocking socket. It is said that it's improve performance in Linux. TODO: check Win32 compatibility. You can try my version in http://mcrg.uib.es:8000/live.ogg (if the server is down, please wait few seconds and try again, I am restarting it frequently for my tests). Conclusions: _very_ stable connection, it recovers from network congestion very nicely. Don't hesitate to ask me for changes or improvements to my patch. <p>Regards, -- ricardo galli gallir@uib.es http://m3d.uib.es/~gallir/ "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch1.diff Type: text/x-diff Size: 9489 bytes Desc: patch1.diff Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20020219/b99eab65/patch1.bin
Jack Moffitt wrote:>As for the other parts, I do not understand why we shouldn't kick >clients who fall 25 packets behind. That is more than 100k usually, and >surely you don't think we should buffer them forever. >well, at 128kbps bitrate, it's only 6 seconds of data. 30 seconds would have been more reasonable, how does everybody think? it might have to be varied based on the bitrate of the stream. liulk <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Just in case, I copy the mail and attach the patch. > > I am working in my second version (not included in the patch), I would like > to hear some comments: > > - prebuffering parameter (used in previous patch) in now configurable in > <limits>...<prebuffer>seconds</prebuffer>... > > - instead of disconnecting when the client-queue > 25, I discard packages > wich are older than prebuffer*2. All clients I tried have recovered very > well, even with a ping -f running behind.These are quite big changes, and warrant some discussion. I was planning to keep a prebuffer internal and spit it out as fast as possible, so this will probably get incorporated. As for the other parts, I do not understand why we shouldn't kick clients who fall 25 packets behind. That is more than 100k usually, and surely you don't think we should buffer them forever. <p>Also, I have not seen any problems with disconnections because of nonblcoking socket failures. They are determined to be recoverable (EAGAIN, etc) or not recoverable. on recoverable errors we just resend. On non recoverable errors we can do nothing but remove the client. I have not yet looked at the patch, so maybe it's correct, but from your description I am doubtful. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 19/02/02 04:10, Jack Moffitt shaped the electrons to say:> > Just in case, I copy the mail and attach the patch. > > > > I am working in my second version (not included in the patch), I would > > like to hear some comments: > > > > - prebuffering parameter (used in previous patch) in now configurable in > > <limits>...<prebuffer>seconds</prebuffer>... > > > > - instead of disconnecting when the client-queue > 25, I discard packages > > wich are older than prebuffer*2. All clients I tried have recovered very > > well, even with a ping -f running behind. > > These are quite big changes, and warrant some discussion.In fact they are small changes in code altough conceptually important. I think the server must try to keep the connection instead of dropping it.> I was planning to keep a prebuffer internal and spit it out as fast as > possible, so this will probably get incorporated.Nice. <p>> Also, I have not seen any problems with disconnections because of> nonblcoking socket failures. They are determined to be recoverable > (EAGAIN, etc) or not recoverable. on recoverable errors we just resend. > On non recoverable errors we can do nothing but remove the client.Two issues, Linux doesn't return always a recoverable error if you try to write when internal TCP buffers are full and/or waiting for some response from the client. In my tests, I was getting "Broken Pipe" continously. Just try it from a client behind a slow connection (ISDN or PSTN) and ask the client to download _a_ web page (for example). The connection is close almost inmediately.> I have not yet looked at the patch, so maybe it's correct, but from your > description I am doubtful.-- ricardo "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.