[mythtv-users] MythTV Frontend for Android released on Market

Raymond Wagner raymond at wagnerrp.com
Fri Feb 24 18:50:57 UTC 2012


On 2/24/2012 12:48, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Raymond Wagner"<raymond at wagnerrp.com>
>> Exactly. The correct version response from the backend is there
>> specifically for that reason.
> Well, the "right" approach was probably to put the protocol version
> *in the server's response banner*.  Is there some compelling reason why that
> wasn't the approach taken, that you know of, Ray?

Right now, the flow is...

Client connects
Client sends version check... MYTH_PROTO_VERSION 72 D78EFD6F
Backend responds correct... ACCEPT
Client announces purpose... ANN Playback mythfrontend 0
Backend responds accepted... OK
Client proceeds with subsequent queries

If the client supports multiple protocol versions, the flow is...

Client connects
Client sends version check... MYTH_PROTO_VERSION 63 3875641D
Backend responds negative... REJECT[]:[]72
Backend drops connection
Client reconnects
Client sends version check... MYTH_PROTO_VERSION 72 D78EFD6F
Backend responds correct... ACCEPT
Client announces and proceeds with subsequent queries

You're suggesting the following instead?

Client connects
Backend sends challange... MYTH_PROTO_VERSION 72
Client sends response... MYTH_PROTO_RESPONSE D78EFD6F
Backend responds correct or drops the connection

That's certainly a much cleaner interface, and I don't have a good 
reason why it wasn't done that way, other than simply no one thought to 
do it.  The check was in place long before I became involved in MythTV, 
and when I implemented the token a year and a half ago, I intentionally 
did it in a manner that would not break the check behavior in existing 
clients.  "Bad" clients might get caught in a loop where the backend 
would continually reject them even though they were passing the correct 
version number, but then "bad" clients were unwanted anyway.


More information about the mythtv-users mailing list