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 <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> 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 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?
>
> 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 <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.
> >
>
>

Reply via email to