Re: [Ovmsdev] Java and questions
I guess from my point of view its better to work on the basis that there can be only one client?
It is possible for there to be more than 1 app connected, controlling the car, but not so likely.
Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response?
I think that every 'C' message will receive a 'c' response. Even if the message is not understood, it will come back with a failure response.
Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects?
The car tries to maintain a connection to the server always. There is no way for the app or server to message or call the car without that connection established. Regards, Mark. On 14 Mar, 2012, at 10:55 PM, Tim Putnam wrote:
Thanks, I think I had the wrong preconceptions here. I guess from my point of view its better to work on the basis that there can be only one client?
Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response?
Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects?
cheers, Tim
On 14 Mar 2012, at 14:17, Mark Webb-Johnson wrote:
Ah I see so the server is just acting as a proxy and carries no state?
Yes. We try to make the server do as little as possible. It is just a store-and-forward relay (for messages) and forward-only relay (for commands and responses).
When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error?
Undefined. Most commands should be ok. Some will have an issue and the original command may get lost (overwritten by the subsequent command).
What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request?
Might break backwards-compatibility. Not sure if we could do it while maintaining compatibility (without having to extend each command).
We could do it on something like the client version. At the moment it is "C 99,p1,p2,p3,etc". We could make v1.3.0 or later handle "C 99-key,p1,p2,p3,etc" and respond with "c 99-key,r1,r2,r3,etc". The problem is that if you send that format to a v1.2.0 client it will fail.
Regards, Mark.
On 14 Mar, 2012, at 10:11 PM, Tim Putnam wrote:
Hi Mark,
Ah I see so the server is just acting as a proxy and carries no state?
When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error?
What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request?
best regards, Tim
On 14 Mar 2012, at 13:45, Mark Webb-Johnson wrote:
Tim,
Sounds real useful.
Please may I also ask a question - what is the model for synchronicity of the messages? On the android app, if I hammer a button, I appear to be able to send more than one command before a response comes from the server. Is this correct? The protocol appears to not allow you to correlate the response from a command to the request (unless I've missed it), so doesn't appear to be asynchronous, although data messages come from the server asynchronously. Is the intended interaction with the server that there is only ever one active command in action?
The command part of the protocol is pretty minimal at the moment. It was added one quite late, and does just the bare minimum of what is needed.
The server doesn't care about the command massages. Any command from the apps it sends to the car (if connected). Any response from the car it sends to _all_ connected apps. The only exception to this is that it does respond to one command itself (the one for GPRS utilization data).
The main limitation is the car module. That can only handle one command at a time, and while it is processing it you shouldn't send any more commands. Most commands will be processed within the same cycle, but some take a second or two.
Regards, Mark.
on 3/14/12 8:26 AM, Mark Webb-Johnson wrote:
It is possible for there to be more than 1 app connected, controlling the car, but not so likely.
Cathy and I are likely to be both monitoring the car from time to time. I expected we'd coordinate on any commands sent to the car, but I wouldn't want anything bad to happen if we both happen to send commands at the same time.
The car tries to maintain a connection to the server always. There is no way for the app or server to message or call the car without that connection established.
There's evidence to suggest that the way the Leaf handles this is by sending a text message to the car telling it to connect to the server to get commands. This way commands only go over the presumably secure and authenticated data connection, but the car only has to listen for text messages when idle. Tom
Answers/Comments, below, in-line On 15 Mar 2012, at 12:08 AM, Tom Saxton wrote:
on 3/14/12 8:26 AM, Mark Webb-Johnson wrote:
It is possible for there to be more than 1 app connected, controlling the car, but not so likely.
Cathy and I are likely to be both monitoring the car from time to time. I expected we'd coordinate on any commands sent to the car, but I wouldn't want anything bad to happen if we both happen to send commands at the same time.
I don't think anything bad could happen, but it is possible for the commands to 'collide' and only one to be active. That said, both Apps would get updated as to the new status, so it would be fairly obvious what is going on.
The car tries to maintain a connection to the server always. There is no way for the app or server to message or call the car without that connection established.
There's evidence to suggest that the way the Leaf handles this is by sending a text message to the car telling it to connect to the server to get commands. This way commands only go over the presumably secure and authenticated data connection, but the car only has to listen for text messages when idle.
Kind of messy, imho. The way we do it seems to require a baseline GPRS network usage of about 30KB/day. That is about 1MB a month and well within most plans. The advantage of the way it is done, is that you can always see the status as of worst-case 10 minutes since the car lost GSM/GPRS connection. Connection to the car is also very very fast (1 to 3 seconds, normally). Regards, Mark.
participants (2)
-
Mark Webb-Johnson -
Tom Saxton