Re: RTMP and Seamless Reload
Hi Aleksandar, Very sorry for the late reply. I was out of the office. > Ah OBS (=Open Broadcaster Software ?) something like this? Yes, the open broadcaster software, that's the tool that we use in our development environment. > How is in general the error handling of the used SW? The software will try to reconnect whenever a network interruption occurs, we have two stream, primary and backup, so when one stream is down, we have other stream to server the request, but this will result in the playlist not being complete for one of the stream, we'd like to minimize that. > * when you reload the backend, does you have also interruption on the stream? Yes, the stream will be disconnected and OBS will try to reconnect again. > * which algo do you plan to use for the backends, `leastconn`? We're using maxconn, we want to limit the number of connection that the backend rtmp server have to 1 only > * How long will a session (tcp/rtmp) normally be? We're planning to stream for tv stations, so in theory it will always be streaming daily until the tv station stops it > * How fast can/will be the reconnect from the clients? It actually depends on the streaming software, in the case of OBS, we can set it to reconnect immediately after disconnection. > * Is it a option to use DSR (=Direct Server Return) for the stream from rtmp source? I am not sure if we can use DSR, I will need to consult with our networking team. > * Which mode do you plan to use http or tcp? We're using TCP. We have tried using the runtime API to maintain current stream without reload and creating new process. We tried having several backends in MAINT state, and when we need one, we will update the ip and port in the runtime configuration. It covers our current needs of not losing any of the existing stream when a new stream arrives, and since they run on the same process, we are sure that the new stream will be routed to the new backend. We plan on going forward using the runtime API for the time being. Thanks, *Erlangga Pradipta Suryanto* *T. *+62118898168| *BBM PIN. D8F39521* *E. esuryanto*@bbmtek.com On Thu, Jan 31, 2019 at 10:39 PM Aleksandar Lazic wrote: > Hi Erlangga. > > Am 31.01.2019 um 06:12 schrieb Erlangga Pradipta Suryanto: > > Hi Aleksandar, > > > > Thank you for your reply. > > As much as possible, we would like the stream to be not interrupted. > > Though at some time, the stream will be closed and restarted. > > We're still at POC stage right now, so we only use one haproxy, > nginx-rtmp server, and OBS to do the streaming > > Ah OBS (=Open Broadcaster Software ?) something like this? > > > https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/ > > > If the current version hasn't supported that yet, we will need to look > for other option other than to reload the configuration. > > We stumbled upon this article about runtime API, > https://www.haproxy.com/blog/dynamic-scaling-for-microservices-with-runtime-api/ > > We are currently testing it. > > The dynamic configuration works like a charm but never the less you will > have some interrupts as this is the nature of all networks. > How is in general the error handling of the used SW? > > I have some questions which you are maybe willing to answer. > > * when you reload the backend, does you have also interruption on the > stream? > * which algo do you plan to use for the backends, `leastconn`? > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4-balance > * How long will a session (tcp/rtmp) normally be? > * How fast can/will be the reconnect from the clients? > * Is it a option to use DSR (=Direct Server Return) for the stream from > rtmp source? > * Which mode do you plan to use http or tcp? > > To get you right you wish to handover the client connected sockets > (tcp/udp/unix) from the `old` process to the new process after a config > reload, right? > > I think this isn't a easy task nor I'm sure it's possible especially when > you run the setup in HA setup with different "machines", but I'm not the > expert about this topic. > > > *Erlangga Pradipta Suryanto* | Software Engineer, BBM > > Regards > Aleks > > > __ > > > > *T. *+62118898168| *BBM PIN. D8F39521*__ > > > > *E. esuryanto*@bbmtek.com <mailto:mtal...@bbmtek.com>__ > > > > Follow us on: Facebook <https://www.facebook.com/bbm/> | Twitter < > https://twitter.com/BBM> | Instagram < > https://www.instagram.com/discoverbbm/> | LinkedIn < > https://www.linkedin.com/company/discoverbbm> | YouTube < > https://www.youtube.com/bbm> | Vidio <https://www.vidio.com/@bbm> > > > > /BBM used under license by Creative Media Works P
Re: RTMP and Seamless Reload
Hi Aleksandar, Thank you for your reply. As much as possible, we would like the stream to be not interrupted. Though at some time, the stream will be closed and restarted. We're still at POC stage right now, so we only use one haproxy, nginx-rtmp server, and OBS to do the streaming If the current version hasn't supported that yet, we will need to look for other option other than to reload the configuration. We stumbled upon this article about runtime API, https://www.haproxy.com/blog/dynamic-scaling-for-microservices-with-runtime-api/ We are currently testing it. *Erlangga Pradipta Suryanto* | Software Engineer, BBM *T. *+62118898168| *BBM PIN. D8F39521* *E. esuryanto*@bbmtek.com Follow us on: Facebook <https://www.facebook.com/bbm/> | Twitter <https://twitter.com/BBM> | Instagram <https://www.instagram.com/discoverbbm/> | LinkedIn <https://www.linkedin.com/company/discoverbbm> | YouTube <https://www.youtube.com/bbm> | Vidio <https://www.vidio.com/@bbm> *BBM used under license by Creative Media Works Pte Ltd **(Co. Regn. No. 201609444E)* This e-mail is intended only for named addressee(s) and may contain confidential and/or privileged information. If you are not the named addressee or have received this e-mail in error, please notify the sender immediately. The unauthorised disclosure, use or reproduction of this email's content is prohibited. Unless expressly agreed, no reliance on this email may be made. On Wed, Jan 30, 2019 at 7:20 PM Aleksandar Lazic wrote: > Hi. > > Am 30.01.2019 um 13:08 schrieb Erlangga Pradipta Suryanto: > > Hi, > > > > I'm trying to use haproxy to proxy rtmp stream to an nginx rtmp backend. > > what we want to achieve is, we will add more nginx rtmp servers on the > backend, and when we do we want to reload the haproxy config without > closing the current stream. > > We tested this by configuring haproxy with one backend and start one > stream, then we update the configuration to include one more backend then > issue the reload command to haproxy. > > The stream is still going but when checking the process and the network > using ps and netstat, the old process is still up and it is still serving > the stream. > > What we had in thought was that the old process could pass the stream to > the new process. > > > > We tried this using haproxy 1.8.17 and 1.9.3 and this is the haproxy > configuration that we use > > > > global > > debug > > log /dev/loglocal0 > > log /dev/loglocal1 notice > > chroot /var/lib/haproxy > > stats socket /run/haproxy/admin.sock mode 660 level admin > expose-fd listeners > > stats timeout 30s > > user haproxy > > group haproxy > > daemon > > > > # Default SSL material locations > > ca-base /etc/ssl/certs > > crt-base /etc/ssl/private > > > > # Default ciphers to use on SSL-enabled listening sockets. > > # For more information, see ciphers(1SSL). This list is from: > > # > https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ > > # An alternative list with additional directives can be obtained > from > > # > https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy > > ssl-default-bind-ciphers > ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS > > ssl-default-bind-options no-sslv3 > > > > defaults > > log global > > modetcp > > option tcplog > > option dontlognull > > timeout connect 5000 > > timeout client 5 > > timeout server 5 > > errorfile 400 /etc/haproxy/errors/400.http > > errorfile 403 /etc/haproxy/errors/403.http > > errorfile 408 /etc/haproxy/errors/408.http > > errorfile 500 /etc/haproxy/errors/500.http > > errorfile 502 /etc/haproxy/errors/502.http > > errorfile 503 /etc/haproxy/errors/503.http > > errorfile 504 /etc/haproxy/errors/504.http > > > > frontend ft_rtpm > > bind *:1935 name rtmp > > mode tcp > > maxconn 600 > > default_backend bk_rtmp > > > > backend bk_rtmp > > mode tcp > > server media01 172.17.1.213:1935 check maxconn 1 weight 10 > > #uncomment the line below then reload > > #server media02 172.17.1.217:1935 check maxconn 1 weight 10 > > > > Is there a way to pass the stream to the new process created by the > reload? > >
RTMP and Seamless Reload
Hi, I'm trying to use haproxy to proxy rtmp stream to an nginx rtmp backend. what we want to achieve is, we will add more nginx rtmp servers on the backend, and when we do we want to reload the haproxy config without closing the current stream. We tested this by configuring haproxy with one backend and start one stream, then we update the configuration to include one more backend then issue the reload command to haproxy. The stream is still going but when checking the process and the network using ps and netstat, the old process is still up and it is still serving the stream. What we had in thought was that the old process could pass the stream to the new process. We tried this using haproxy 1.8.17 and 1.9.3 and this is the haproxy configuration that we use global debug log /dev/loglocal0 log /dev/loglocal1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). This list is from: # https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ # An alternative list with additional directives can be obtained from # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults log global modetcp option tcplog option dontlognull timeout connect 5000 timeout client 5 timeout server 5 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend ft_rtpm bind *:1935 name rtmp mode tcp maxconn 600 default_backend bk_rtmp backend bk_rtmp mode tcp server media01 172.17.1.213:1935 check maxconn 1 weight 10 #uncomment the line below then reload #server media02 172.17.1.217:1935 check maxconn 1 weight 10 Is there a way to pass the stream to the new process created by the reload? Thank you, *Erlangga Pradipta Suryanto* | Software Engineer, BBM *T. *+62118898168| *BBM PIN. D8F39521* *E. esuryanto*@bbmtek.com Follow us on: Facebook <https://www.facebook.com/bbm/> | Twitter <https://twitter.com/BBM> | Instagram <https://www.instagram.com/discoverbbm/> | LinkedIn <https://www.linkedin.com/company/discoverbbm> | YouTube <https://www.youtube.com/bbm> | Vidio <https://www.vidio.com/@bbm> *BBM used under license by Creative Media Works Pte Ltd **(Co. Regn. No. 201609444E)* This e-mail is intended only for named addressee(s) and may contain confidential and/or privileged information. If you are not the named addressee or have received this e-mail in error, please notify the sender immediately. The unauthorised disclosure, use or reproduction of this email's content is prohibited. Unless expressly agreed, no reliance on this email may be made.
