[vdr] Re: How to kill an svdrp connection from vdr ?

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

On Tue, 2004-10-26 at 13:51 +0200, Nicolas Huillard wrote:
> Klaus Schmidinger a écrit :
> >>>Philip Lawatsch wrote:
> ...
> >>>>Klaus Schmidinger wrote:
> ...
> >>>>>As I've stated in a previous post, there is a rather simple
> >>>>>solution to this. Every SVDRP connection will have to issue an LSTT
> >>>>>command before it may add, modify or delete a timer. The timer list will
> >>>>>have a timestamp marking when the last modification was made. If an SVDRP
> >>>>>connection issues a timer modification command, but the list of timers was
> >>>>>in some way modified after this sessions last LSTT command, it will get
> >>>>>an error message, saying that the timers were modified in the meantime,
> >>>>>and that it should do another LSTT.
> >>>>
> >>>>Which for sure will break a lot of applications anyway.
> ...
> > If the application doesn't know an error, then it should treat it
> > as an "unknown error". After all, I _must_ be free to add new error
> > messages as they become necessary!
> ...
> 
> In order to use a generic proxy, the implied modifications are :
> * modify VDR in order to check the timestamp of the previous LSTT for 
> every ???T command that occurs after it
> * modify each application to send the timestamp of the last LSTT to each 
> ???T command. They simply will receive an error when DELT and we're right.

This sounds very complicated.

Is the multiple svdrp at once problem really that hard to solve?

All that really needs to be done is to modify the code so the state is
stored.  Ie each svdrp conection has its own table of timers, recordings
etc.  These tables are either populated at startup or at each LST?
command.

Now: as has been stated before (By Klaus).  The real problem here exists
independently of multiple svdrp connections:  what happens if a svdrp
client does LSTT, and then DELT but in the meantime that timer has been
deleted?  Even with only one svdrp client this can happen by the user
using the main menu, vdr automatically deleting a recording due to disk
space, vdr removing a timer because it has ended etc etc etc.

So, for correctness, regardless of the number of svdrp connections, this
problem needs to be resolved.

SVDRP needs to say 'I did not delete/modify that
timer/recording/whatever because it was not what you thought it was'.

It the simple model this can be based on timestamps (Is the information
from the last lst? still valid?).  In the complex model, where state is
preserved in the svdrp handler, this can be based on if this object
still exists.

Client compatibility is not an issue.  The svdrp protocol is broken and
unsafe at the moment and must be fixed.


> If a SVDRP-aware proxy is written, then it will implement either the VDR 
> side or the application side... or both.
> Translated in development tasks :
> * either Klaus works at modifying SVDRP handling, but I'm sure he was 
> ironic...
> * or every application developper implement the necessary stuff
> * *and* someone take the proxy task
> * *or* someone implement everything in a SVDRP proxy, independently of 
> everything else...
> 
> (note that this solution is not elegant, as in introduce a stateful 
> inspection where it is not mandatory, as someone already said earlier - 
> stateless SVDRP would be much more simpler for everyone - that is : if 
> state must not be emulated at the client side, like cookies in HTTP)
> 
> (I think a real client-server VDR would be a Good Idea - multiple 
> clients, multiple servers - separating boths commands, OSD, timers, 
> ouput device, etc. Multi-client SVDRP would be the first step)
>