Icecast Streaming Media Server

[DJ-Zath]

hi everyone!

if someone out there has any suggestions for this issue, I'd appreciate it..

first, the situation:

I have written code that lets an Eggdrop bot log into icecast via an authed connection (no easy task!) it uses an external connection-handler to achieve this via fetch. As far as Icecast, it sees a auth-connection from a localhost source...

now the issue:

simply put, Eggdrop opens the connection to Icecast, data is read PERFECTLY and then Eggdrop closes the connection... however, Icecast does NOT.

the problem is that Eggdrop will "poll" Icecast once every 2 seconds.. and since Icecast isn't releasing the socket- nor closing the connection, I end up with a minimum of 20 dead sockets waiting to time out!

notice I said MINIMUM.. I have seen as many (so far) as 60!

thats just way too many!

I have quickly traced the problem down to icecast holding the socket open for 60 seconds after the connection was closed by the Eggdrop...

am I doing something wrong?

orginally, I was using Eggdrop internal socket-handling code.. but gave up on that since I was unable to get TCL to function properly.. so I'm calling an external connection-handler and thats doing a much-better job talking to Icecast..

lessening the poll-counts will put the Eggdrop 2 minutes "behind".. this is unacceptable, of course, since then Eggdrop will be displaying song titles to songs that have allready ENDED!

so, the solution will either: have to get Icecast to properly close the sockets or live with knowing that the server can crash/run out of resources if it becomes under load for any signaficient amount of time!
(note the latter is cirtainly unreasonable!)

again, I'd appreciate any suggestions on this matter.. thanks!

-DjZ-

[karlH]

we do not set any timeout like that. If you connect as a listener listener then close the socket then icecast will notice as soon as it sends the next fragment of audio for the stream (so maybe a second assuming a low bandwidth stream). It does not just keep the socket around then close after 60 seconds. I've heard of proxies keeping a connection open but that should of been resolved with 2.3.2

karl.

[DJ-Zath]

Hi Karl!

thanks for the prompt reply..

Perhaps I wasn't clear on what type of connection the Eggdrop establishes.. Icecast sees it as a browser/http auth connection logging into the admin page- The Eggdrop retrieves "stats.xml" then closes.. I see the connections in the "netstat" list as a set of 20 to 60 "TIME_WAIT"s (and/or sometimes "FIN_WAIT_2"s..). the connectio is via localhost- and I have "127.0.0.1" set as a socket/port option.. from what I can tell, every connection from the Eggdrop is successful.. it just doesn't close the cconnection on Icecast's side..

please observe the following:

Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.60657 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.58889 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.59189 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.52827 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.60289 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.51351 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.55903 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.63632 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.49503 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.49811 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.58159 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.52294 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.55011 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.61101 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.53465 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.56546 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.55570 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.62535 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.52130 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.57381 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.51604 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.56640 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.49782 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.62408 TIME_WAIT
tcp4 0 0 localhost.warp-r.8000 localhost.warp-r.60774 TIME_WAIT

and so on and so on....

what you see there is the Eggdrop and Icecast.. (and, if I'm reading that correctly, its icecast thats "waiting to time out")

I donno why Icecast would be doing this.. I'm calling :

fetch -q -A -m -T 1 -o - "http://$AdmLogin:$AdmPass@$CastIP:$CastPort/ad
min/stats.xml

CastIP = 127.0.0.1
CastPort = 8000
AdmLogin = undisclosed
AdmPass = undisclosed

-DjZ-

[karlH]

You are not reading it correctly. The netstat shows a TIME_WAIT state on those sockets, so icecast has already closed them. The socket is in a state of waiting for the last ack to be received or timeout after a while. If you are sure that the client is closing the socket then check the network packets to see what is going over the interface.

karl.

[DJ-Zath]

thanks for the reply, Karl...

So, you're saying that the eggdrop (or, in actuality, the unix fetch command) is not receiving or accepting the last ack from icecast?

hmmmmm

(yet it working for remote connections.. only then with icecast is it not receiving the last ack...)

I'll run some more tests...

(now I'm REALLY puzzled...)

-DjZ-

[karlH]

try to monitor one of these connections over the link and see if it matches the tear down procedure for a tcp socket.

karl.