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 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 <al-hapr...@none.at > <mailto:al-hapr...@none.at>> 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/log local0 > > log /dev/log local1 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 > > mode tcp > > option tcplog > > option dontlognull > > timeout connect 5000 > > timeout client 50000 > > timeout server 50000 > > 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 <http://172.17.1.213:1935> > check maxconn 1 weight 10 > > #uncomment the line below then reload > > #server media02 172.17.1.217:1935 <http://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? > > Well afaIk is this not possible with the current versions. > Why isn't a reconnect to the new process not good or possible? > Which SW is in use between haproxy? > > > Thank you, > > > > *Erlangga Pradipta Suryanto* | Software Engineer, BBM > > Regards > Aleks > > > __ > > > > *T. *+62118898168| *BBM PIN. D8F39521*__ > > > > *E. esuryanto*@bbmtek.com <http://bbmtek.com> > <mailto:mtal...@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 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. > > >
