Posts: 3,415
Threads: 158
Joined: Jan 2006
On my IPhone using 3g the latency is 500ms 10mi from my house. So you would incur about 3/4 sec latency to get each TCP connection established before you can transmit any data. And 1/2 sec latency for each request/response. Of course at greater distances or on Edge this number would go up.
If you use multiple connections you are going to have to deal with the added latency to establish each connection, (if they are opened serially). On the other hand, if you can only fetch one image at a time on a single connection, then the latency is going to get you that way too.
So things like TCP connection pooling and reusing existing connections might provide optimal results. If you don't want to look into that stuff for this release, i'd be happy to help do an analysis after you release.
Posts: 40,483
Threads: 491
Joined: Aug 2002
It looks like we missed having an OK key in the list of hot keys. The NEVO has one, and Sergio wants to be able to map that to a hot key with that name, and it'll probably be very common. So I'm going to add an OK hot key. There's no particular reason for existing clients to implement this key at this time. It just means that client will never send it. So I'm not going to bump the protocol version for just this simple change that won't affect existing clients.
But just incorporate it in a subsequent release if it makes sense for your particular platform.
Dean Roddey
Explorans limites defectum
Posts: 362
Threads: 10
Joined: Sep 2009
Looking at the user responses about the iPhone RIVA client, it seems that the speed hasn't been a problem so far. But I do see some complaints that when the connection is broken (either due to a network problem or by the device going to sleep), the client can't pick up where it left off. I can imagine how that would be quite annoying.
Would it be possible for a future revision to the RIVA protocol to include some sort of "mileposting" system, where the server sends a number or ID indicating where in the interface tree the user was, which the client can remember and send back at reconnection time?
This could be something the RIVA server handles itself, by sending the name of each new template as it is loaded, and letting the client send the desired template name at login time.
Or it could be something where the onus is put onto the template maker, with the addition of a special command that templates can use to send a number or ID with the current state, and a RIVA command that clients use to send back that state (in the same way that they send hot keys now). Does that make sense?
Posts: 40,483
Threads: 491
Joined: Aug 2002
There's no way that would work, because where they are can include multiple levels of nested interfaces and various variables and such, all of which were set up dynamically as things were done.
The only think that would work would be to allow the server to keep going on that session for a while and allow the client to reconnect, which would introduce a lot of complexities as well, but would be at least theoretically possible.
Dean Roddey
Explorans limites defectum
Posts: 1,277
Threads: 142
Joined: Oct 2005
Dean, are GVars retained across logouts/ins for a particular account in RIVA?
Posts: 40,483
Threads: 491
Joined: Aug 2002
No. They are per session. When you log in, that's just the same as starting up the regular viewer.
Dean Roddey
Explorans limites defectum
Posts: 1,907
Threads: 76
Joined: Feb 2004
SamVimes2 Wrote:Dean, are GVars retained across logouts/ins for a particular account in RIVA?
No, each session is a new instance starting fresh, much like a new IV session created by stopping/starting the interface viewer.
Mark Stega
Posts: 246
Threads: 38
Joined: May 2007
Dean Roddey Wrote:There's no way that would work, because where they are can include multiple levels of nested interfaces and various variables and such, all of which were set up dynamically as things were done.
I'm one of the complainers and I can really see Dean's point about a user being nested many levels deep with all sorts of things going on. I'm sure that applies to those of us who use overlays almost exclusively which would be pretty hard to track. I guess a programatic solution to this would not be a trivial task.
Based on what I'm hearing this really isn't going to be something that is possible without some major changes. Therefore I think the next best thing for now is to get the client to reconnect automatically and simply load the default template. That would at least get us away from the error message and having to restart manually every time.
The iTouch is a really an inexpensive way to put portable touchscreen interfaces all over the place and with the new Apple Slate product coming this year I think it's easy to see there will be a great demand for all of these items. The iPhone client is a tremendous version 1 product. Just think of the possibilities.
Posts: 40,483
Threads: 491
Joined: Aug 2002
The most reasonable scenario would be to allow the server to keep a session open in a reattachable way for some short amount of time, so that a temporary loss of connection doesn't destroy the session. But that would require some new functionality in the server and clients.
Dean Roddey
Explorans limites defectum
Posts: 246
Threads: 38
Joined: May 2007
Dean Roddey Wrote:The most reasonable scenario would be to allow the server to keep a session open in a reattachable way for some short amount of time, so that a temporary loss of connection doesn't destroy the session. But that would require some new functionality in the server and clients.
It's the short amount of time that I'm worried about. Peoples definition of short will be all over the place. I'd need the connection to stay active for at least an hour.
