redirect

[faf5678]

this is a feature suggestion.
there should be 3 ports allocated to the livereplay service as a whole.
2 instances running at the same time should be supported.
the primary server listens on the primary port and one of the secondary ports.
when the service needs to be restarted, the primary will stop listening on the primary port
and a new primary will be started listening on 2 ports.
any request coming into the new primary will be redirected to the now secondary if
the replay id references a replay that is still being handled by the old primary server.
this allows the server to be restarted at any time without interrupting active connections.

[Sheeo]

👍

[Eximius]

Why not just have single server that can stop listening on its tcp socket on an IPC signal? We can use http for live replay upload as well. It can run happily until all its tasks are finished.

[faf5678]

all replay listeners must connect to the process to which the replay writers actually write.
consequently, all replay writers should write to the same process or else we have to come up
with another complicated workaround as to which process actually writes the replay to disk.
so all connections that refer to replays in the old process must be redirected there.
(it will still finish eventually, since no new replays are added)

[Eximius]

Livereplay server should buffer the replays into a file anyway... We can just have a livereplay viewing be a simple http service that streams the replay out of the file.

[faf5678]

you cant use a http server - the file would be growing as it is being uploaded.
then if you have to implement the server yourself anyway, why do http bloat where its not required.
using a file for synchronization is possible. requires more redesign than a redirect though and has
no inherent advantages. plus some I/O overhead.

[Eximius]

HTTP is not bloat. File is cached in kernel if it is being used. There is no I/O overhead in reading a file from memory. A stock HTTP server would actually be able to stream replay files as they are being written to the filesystem (assuming the kernel is not windows and doesn't throw EOF for no reason).

This unifies the access to replays across livereply and replay download as well.

[faf5678]

redirect -> no I/O necessary. no synchronization across process boundaries necessary.
http for unification is rational though.

[Eximius]

redirect -> Hold everything in memory because bob is not streaming his part fast enough. Massive synchronization in the same process

[Eximius]

Scratch that, you have to hold everything in memory due to new clients getting the stream.

(In redirect method)

[Sheeo]

Using http we get handling of slow clients for free as well, since good reverse proxies like nginx handle this pretty well.

[faf5678]

we dont need to change the lobby.
https://gitorious.org/python-fdsend/pages/Home