|
Roberto Nibali wrote:
> > However
> > simple cases might be amenable to solution eg read only
> > streaming video. If a realserver fails in the middle of
> > tranferring a video presentation to an important set of
> > business prospects, they are not likely to be impressed.
>
> But for this the application needs to be failover aware.
yes. The client would need to maintain state incase the
server failed. I think ncftp does something like this.
The server(s) would have to maintain state and exchange
state with the other realservers in the LVS incase the
realserver or the client failed. I expect
that some GPL'ed piece of code would be very happy if
someone wrote code to do this.
> The transition time alone is a multiple longer than audio would ever
> accept it.
I expect the transition will be obvious to the client.
You will at least have to wait for the timeouts. I'm assuming
people would be happy with the video restarting automatically,
even if it took several seconds, rather than the whole show
just stopping. You've got to start somewhere and a implementation
that works at all, even if badly, is a first step.
> For audio streams you also mostly don't rely on unicast which
> would be another source of problem for LVS.
I just said "let's try a simple case"
> As for http RS failover we
> could use the server pool implementation which is still on my hd somewhere.
neat
> > video stream. The streaming_videod would also have to know
> > when and how to start up a new session using this state information.
>
> The hifi multimedia folks have come up with their own implementations,
> tweaks and protocols for streaming and processing over the years.
I haven't a clue what's going on in this area. Can you give me
any pointers?
> Now I don't really want to spoil the mood here so I suggest you guys
> interested in transparent RS failover should have a look at Werner
> Almensberger's paper on "TCP connection passing". Joe, the paper can be
> found in the 2004 OLS proceedings, Volume 1, first paper ;). The basic
> idea is to synchronise the ICI (internal connection information) of a
> socket over the nodes. Oh, the homepage can of course be found at:
yeah yeah, I went to the talk. It's all vaporware and proposal.
He didn't have anything working. People shouldn't be allowed to
give talks that are only proposals.
He is tackling the difficult problem of migrating _any_ tcp
connection without help from the application.
I did learn something from his talk (so I guess there was some
point in giving it) - that no-one is going to solve this anytime
real soon. In the meantime it might be possible to handle realserver
failure for a readonly stream of data where the number of frames
is known ahead of time and packets arrive at predictable intervals.
Joe
--
Joseph Mack PhD, High Performance Computing & Scientific Visualization
LMIT, Supporting the EPA Research Triangle Park, NC 919-541-0007
Federal Contact - John B. Smith 919-541-1087 - smith.johnb@xxxxxxx
|
