Hi !

Le mercredi 29 décembre 2010 20:01:05, Cees van Egmond a écrit :
> Furthermore, in both setup's above the following happens while forcing the
> connection to go down:
> 0sec. sudo route del default (force the connection down)
> 8sec. listening to the source via icecast gets down.
> 93/94sec. Liquidsoap reports the first signs of disconnection:
> 
> 2010/12/29 19:54:18 [11909090:2] Cry socket error: could not write data to
> host: Unix.Unix_error(2, "write", "")!
> 2010/12/29 19:54:18 [11909090:3] Closing connection...
> 2010/12/29 19:54:18 [11909090:3] Will try to reconnect in 3 seconds.
> 2010/12/29 19:54:18 [clock.wallclock_icecast:2] Too much latency! Resetting
> active sources...
> 2010/12/29 19:54:18 [11909090:3] Connecting mount 11909090 for
> sou...@...... 2010/12/29 19:54:21 [11909090:3] Connection setup was
> successful.
> 
> In my on_disconnect I included to restore the route, so connecting again
> works directly after 3 secs of disconnection.
> But now I have an 93/94 seconds of disconnection without action of
> Liquidsoap. How can I setup Liquidsoap to reconnect much faster?

Hmm..
I am not sure that forcing a deconnection through deleting the route is the 
best way to proceed. By default, icecast output is set with a pretty high 
timeout (30 sec). For most users, this is expected: there are buffers all over 
the place and one would expect the system to be robust in terms of network 
lags.

Now, concerning your case, you have more than 30 sec. of delay. In fact I do 
not really know what happens internaly when you unset the route. It seems to 
me that you keep on filling the socket until the system can't take more and 
returns an error in Unix.write.

I have just commited some changes in liquidsoap regarding those issues. First, 
nodelay is now set on output.icecast's connection, which should help reducing 
intermediate buffering. Second, you can now set the timeout. You may try to 
pass:
  timeout=5. 
in output.icecast.

However, the more I read about posix socket and timeout, the more I am 
confused about the portability and implementation of those things.. I'll be 
vary happy if you could report whether this helps or not :)

Romain

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to