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 <mtal...@bbmtek.com>



On Thu, Jan 31, 2019 at 10:39 PM Aleksandar Lazic <al-hapr...@none.at>
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 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.
> >     >
> >
>
>

Reply via email to