| View previous topic :: View next topic |
| Author |
Message |
maniac
Guest
|
 Posted: Thu Oct 06, 2005 9:43 pm Post subject: Relay on demand problem |
 |
|
Hello! I have some problem with relay on demand function. I'm relaing few streams. But in some cases i see streange behavior of icecast. When the client connects, icecast will connect to master stream server, stream is relayed to client, then after few seconds it disconnects from master server, and after sending all data in buffer to client the client will be also disconnected. This situation is constantly repeating.
I'm using Icecast 2.3.0
Relay secion from config:
| Code: |
<relay>
<server>213.251.129.32</server>
<port>82</port>
<mount>/</mount>
<local-mount>/RadioFotka48.mp3</local-mount>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
<on-demand>1</on-demand>
</relay>
|
And that what i see by TCPDUMP
| Code: |
23:42:03.144074 IP 85.219.198.194.47166 > 213.251.129.32.80: S 3882354151:3882354151(0) win 5840 <mss 1460,sackOK,timestamp 7822850 0,nop,wscale 2>
23:42:03.191895 IP 213.251.129.32.80 > 85.219.198.194.47166: S 3279315899:3279315899(0) ack 3882354152 win 5792 <mss 1460,sackOK,timestamp 116798024 7822850,nop,wscale 0>
23:42:03.191934 IP 85.219.198.194.47166 > 213.251.129.32.80: . ack 1 win 1460 <nop,nop,timestamp 7822898 116798024>
23:42:03.192273 IP 85.219.198.194.47166 > 213.251.129.32.80: P 1:63(62) ack 1 win 1460 <nop,nop,timestamp 7822898 116798024>
23:42:03.238925 IP 213.251.129.32.80 > 85.219.198.194.47166: . ack 63 win 5792 <nop,nop,timestamp 116798029 7822898>
23:42:03.244709 IP 213.251.129.32.80 > 85.219.198.194.47166: P 1:172(171) ack 63 win 5792 <nop,nop,timestamp 116798030 7822898>
23:42:03.244741 IP 85.219.198.194.47166 > 213.251.129.32.80: . ack 172 win 1728 <nop,nop,timestamp 7822951 116798030>
[CUT]
23:42:06.089691 IP 213.251.129.32.80 > 85.219.198.194.47166: P 343549:344501(952) ack 63 win 5792 <nop,nop,timestamp 116798314 7825751>
23:42:06.089728 IP 85.219.198.194.47166 > 213.251.129.32.80: . ack 344501 win 16022 <nop,nop,timestamp 7825796 116798313>
23:42:06.115662 IP 213.251.129.32.80 > 85.219.198.194.47166: . 344501:345949(1448) ack 63 win 5792 <nop,nop,timestamp 116798317 7825751>
23:42:06.116027 IP 213.251.129.32.80 > 85.219.198.194.47166: . 345949:347397(1448) ack 63 win 5792 <nop,nop,timestamp 116798317 7825751>
23:42:06.116066 IP 85.219.198.194.47166 > 213.251.129.32.80: . ack 347397 win 16022 <nop,nop,timestamp 7825823 116798317>
23:42:06.116282 IP 213.251.129.32.80 > 85.219.198.194.47166: . 347397:348845(1448) ack 63 win 5792 <nop,nop,timestamp 116798317 7825751>
23:42:06.116553 IP 85.219.198.194.47166 > 213.251.129.32.80: R 63:63(0) ack 348845 win 16022 <nop,nop,timestamp 7825823 116798317>
23:42:06.116673 IP 213.251.129.32.80 > 85.219.198.194.47166: . 348845:350293(1448) ack 63 win 5792 <nop,nop,timestamp 116798317 7825751>
23:42:06.116715 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.117545 IP 213.251.129.32.80 > 85.219.198.194.47166: . 350293:351741(1448) ack 63 win 5792 <nop,nop,timestamp 116798317 7825751>
23:42:06.117596 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.135287 IP 213.251.129.32.80 > 85.219.198.194.47166: P 351741:352693(952) ack 63 win 5792 <nop,nop,timestamp 116798319 7825796>
23:42:06.135320 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.156133 IP 213.251.129.32.80 > 85.219.198.194.47166: . 352693:354141(1448) ack 63 win 5792 <nop,nop,timestamp 116798321 7825796>
23:42:06.156180 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.156565 IP 213.251.129.32.80 > 85.219.198.194.47166: . 354141:355589(1448) ack 63 win 5792 <nop,nop,timestamp 116798321 7825796>
23:42:06.156604 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.156754 IP 213.251.129.32.80 > 85.219.198.194.47166: . 355589:357037(1448) ack 63 win 5792 <nop,nop,timestamp 116798321 7825796>
23:42:06.156796 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.157516 IP 213.251.129.32.80 > 85.219.198.194.47166: . 357037:358485(1448) ack 63 win 5792 <nop,nop,timestamp 116798321 7825796>
23:42:06.157556 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
23:42:06.157888 IP 213.251.129.32.80 > 85.219.198.194.47166: . 358485:359933(1448) ack 63 win 5792 <nop,nop,timestamp 116798321 7825796>
23:42:06.157926 IP 85.219.198.194.47166 > 213.251.129.32.80: R 3882354214:3882354214(0) win 0
|
Of course I've cheched. This is not problem of master server. When I'm connecting directly nothing is broking the connection.
[/quote] |
|
| Back to top |
|
 |
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Thu Oct 06, 2005 10:39 pm Post subject: |
|
|
If the link to the master is dropped (and no fallback is setup) then the listener will be disconnected. The tcpdump tends to suggest that the player sends a TCP reset therefore causing the relay to shutdown.
While I don't know why the player is aborting the connection, One possibility is that the master is bursting a large amount of data which is going through icecast and causing the player to choke or be treated as a slow listener. If that is the case you could increase the queue-size to something larger or maybe define an intro file to play to the listener before trying the stream.
karl |
|
| Back to top |
|
|
maniac
Guest
|
| Posted: Fri Oct 07, 2005 1:06 pm Post subject: |
|
|
That what i see on the player side, and on the master server side
Master server:
| Code: |
14:55:21.747242 IP 85.219.198.194.56771 > 213.251.129.32.80: S 1599222805:1599222805(0) win 5840 <mss 1460,sackOK,timestamp 62629784 0,nop,wscale 2>
14:55:21.792393 IP 213.251.129.32.80 > 85.219.198.194.56771: S 957559449:957559449(0) ack 1599222806 win 5792 <mss 1460,sackOK,timestamp 122277529 62629784,nop,wscale 0>
14:55:21.792432 IP 85.219.198.194.56771 > 213.251.129.32.80: . ack 1 win 1460 <nop,nop,timestamp 62629829 122277529>
[CUT]
14:55:25.373366 IP 85.219.198.194.56771 > 213.251.129.32.80: . ack 235586 win 16022 <nop,nop,timestamp 62633411 122277882>
14:55:25.373689 IP 213.251.129.32.80 > 85.219.198.194.56771: . 235586:237034(1448) ack 63 win 5792 <nop,nop,timestamp 122277882 62633282>
14:55:25.373741 IP 213.251.129.32.80 > 85.219.198.194.56771: P 237034:237986(952) ack 63 win 5792 <nop,nop,timestamp 122277882 62633282>
14:55:25.373886 IP 85.219.198.194.56771 > 213.251.129.32.80: R 63:63(0) ack 237986 win 16022 <nop,nop,timestamp 62633411 122277882>
14:55:25.469307 IP 213.251.129.32.80 > 85.219.198.194.56771: . 237986:239434(1448) ack 63 win 5792 <nop,nop,timestamp 122277891 62633409>
14:55:25.469347 IP 85.219.198.194.56771 > 213.251.129.32.80: R 1599222868:1599222868(0) win 0
14:55:25.469606 IP 213.251.129.32.80 > 85.219.198.194.56771: . 239434:240882(1448) ack 63 win 5792 <nop,nop,timestamp 122277891 62633409>
14:55:25.469650 IP 85.219.198.194.56771 > 213.251.129.32.80: R 1599222868:1599222868(0) win 0
14:55:25.469982 IP 213.251.129.32.80 > 85.219.198.194.56771: P 240882:242330(1448) ack 63 win 5792 <nop,nop,timestamp 122277891 62633409>
14:55:25.470020 IP 85.219.198.194.56771 > 213.251.129.32.80: R 1599222868:1599222868(0) win 0
|
Of course icecast is working on 85.219.19.194, and the master server addr 213.251.129.32
on the plistener side:
| Code: |
14:55:21.540471 IP 172.20.20.20.1686 > 172.31.0.2.8000: S 1572132970:1572132970(0) win 16384 <mss 1460,nop,nop,sackOK>
14:55:21.540509 IP 172.31.0.2.8000 > 172.20.20.20.1686: S 1607847358:1607847358(0) ack 1572132971 win 5840 <mss 1460,nop,nop,sackOK>
14:55:21.540712 IP 172.20.20.20.1686 > 172.31.0.2.8000: . ack 1 win 17520
14:55:21.640190 IP 172.20.20.20.1686 > 172.31.0.2.8000: P 1:142(141) ack 1 win 17520
14:55:21.640218 IP 172.31.0.2.8000 > 172.20.20.20.1686: . ack 142 win 6432
14:55:21.892304 IP 172.31.0.2.8000 > 172.20.20.20.1686: P 1:360(359) ack 142 win 6432
14:55:21.892389 IP 172.31.0.2.8000 > 172.20.20.20.1686: P 360:1760(1400) ack 142 win 6432
14:55:21.893002 IP 172.20.20.20.1686 > 172.31.0.2.8000: . ack 1760 win 17520
14:55:21.893036 IP 172.31.0.2.8000 > 172.20.20.20.1686: . 1760:3220(1460) ack 142 win 6432
[CUT]
14:55:25.568953 IP 172.31.0.2.8000 > 172.20.20.20.1686: . 127036:128496(1460) ack 142 win 6432
14:55:25.568965 IP 172.31.0.2.8000 > 172.20.20.20.1686: . 128496:129956(1460) ack 142 win 6432
14:55:25.568977 IP 172.31.0.2.8000 > 172.20.20.20.1686: . 129956:131416(1460) ack 142 win 6432
14:55:25.568986 IP 172.31.0.2.8000 > 172.20.20.20.1686: FP 131416:132876(1460) ack 142 win 6432
14:55:25.569978 IP 172.20.20.20.1686 > 172.31.0.2.8000: . ack 131416 win 7300
14:55:25.570020 IP 172.20.20.20.1686 > 172.31.0.2.8000: . ack 132877 win 5840
14:55:26.928237 IP 172.20.20.20.1686 > 172.31.0.2.8000: . ack 132877 win 17520
14:55:33.194389 IP 172.20.20.20.1686 > 172.31.0.2.8000: F 142:142(0) ack 132877 win 17520
14:55:33.194427 IP 172.31.0.2.8000 > 172.20.20.20.1686: . ack 143 win 6432
|
And here server addres is 172.31.0.2, and the listener addres is 172.20.20.20
As You see icecast first reseted the connection to ( time 14:55:25.373886 ) and then, it was sent FIN to listener (time 14:55:25.568986). I don't know it will be helpfull but i thing that may be some problem with decoding of input stream as the problems accours only with some stations. Generaly every station that connection is dropping have intro. |
|
| Back to top |
|
|
maniac
Guest
|
| Posted: Fri Oct 07, 2005 1:21 pm Post subject: |
|
|
| Incresing queue size from 102400 to 10240000 solved problem. But I'm wondering is it the way it should be? |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Fri Oct 07, 2005 2:48 pm Post subject: |
|
|
| maniac wrote: |
| Incresing queue size from 102400 to 10240000 solved problem. But I'm wondering is it the way it should be? |
please note that I don't have that much to work on here, a tcp snapshot will only tell me part of the story, the error log may help determine the actual reason for any action icecast does. The fact that the larger queue size worked would tend to indicate that the master server sent a large amount of stream data initially (ie some burst data). With a small queue size, the icecast to player connection may not of been able to handle the bitrate and hits the lower queue-size limit, which in turns drops the listener (too far behind), then terminates the stream as there are no listeners on it anymore.
If that is the reason, then there isn't currently a way skip that flood of data so the large queue-size allows for soaking it all up. You can add an intro file for the on-demand relay which will delay when the new listener gets onto the stream queue but you'll have to experiment on the best settings as it's hard to determine from here. Don't worry too much about the large queue-size as the queue will shrink if there's no slow listeners.
karl. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2002 phpBB Group
subRebel style by ktauber
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
