Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DSKO]

Hi!

I am developing a JRiver Media Center driver for RTI home automation systems using MCWS,
and I have a change request for MCWS.

The RTI drivers must handle asyncronous events from the RTI processors,
such as button-presses, multiple devices, system changes and so on.

I try to have just one connection to MC with MCWS,
and for example poll using Playback/Info, Playback/Repeat, Playback/Shuffle to get
the total state of MC to be able to show the correct state in the RTI devices.

The problem I have now, is that Playback/Repeat and Playback/Shuffle (and partly UserInterface/Info)
return the same response tags and attributes (Mode), and I can't differentiate between the responses!

Yes, the responses will return in the same order and sequence as the requests,
but if there are communication problems, requests can get lost,
and then I can't be sure which request the next OK response belongs to.
So this needs to be handled another way.

I can make a workaround by creating another connection just for polling Playback/Repeat (or shuffle),
but that is of course not a good way of solving this, IMHO.

So I would like to have MCWS in the responses return the function name it is a response of,
maybe as an attribute on the root-element Response like this:

Code: [Select]

<Response Function="Repeat" Status="OK">
   <Item Name="Mode">Off</Item>
</Response>

(This shouldn't break compatibility, if solutions using MCWS
are parsing the XML correctly.)

Am I missing something here; are there other solutions to the problem that I'm not aware of?

Espen

[Hendrik]

Request and Response are always handled on the exact same connection to the HTTP server, if you track those connections you can associate a request and response perfectly to each other without any questions.

In fact, I'm quite puzzled how you would design a HTTP client to send requests and then somehow lose the association between requests and responses. Its not like MC calls you with the response, you call MC - and in the same call MC responds.
Every HTTP client implementation I've ever seen gives you the response as a return to the request, before you can even use the connection again to do something else.

[DSKO]

I queue up the requests and then write multiple requests per open HTTP socketconnection,
so that I don't need to open and close the socket unnecessary.
After the write, I get asyncronous responses back whenever they are coming from MC.
This works beautifully, but when something fails with the connection after the writeoperation,
I don't know how many of these requests actually arrived at the MC HTTP server.
If the responses contained the name of the function or some correlation with the request, this wouldn't be a problem.

But I have now bitten the bullet and changed this so that I open the connection,
wait for the response and then read it (or get a connection error), and then close it for each request.
Not as efficient and elegant...

I still think the responses should contain the function name or some kind of correlation with the request,
then parsing of the responses would be easier, and it would be easier to write multiple requests per connection,
and by that more efficient communication.

[MrC]

You have TCP sequence numbers, no?

[DSKO]

No...

But I've made some changes again.
Now I write the request, wait for the response,
but now I keep the connection open if there are more requests waiting,
if not, I close the connection.

But I STILL want the function name in the response...

[Hendrik]

The function name is kinda pointless, what if I ask the same function with different parameters to deliver different information? You still wouldn't be able to sync those up.
I think your HTTP Client is in serious need of a re-design.

You don't need to open/close the connection, you can re-use it of course, but the way HTTP works, you can send one request, and you HAVE to wait for the response before you can send another request over the same connection.
HTTP itself is not asynchronous. However you implemented your HTTP client, its adding a huge complexity into the process which the HTTP protocol itself does not support even. Internally it still has to sync up requests and responses, but somewhere down the line this sync is lost.

I mean, you can never rely on any normal HTTP server to tell you which page exactly he is transferring to you, you have to track this yourself, as the server will answer the response immediately, and not in an async fashion.

[DSKO]

I didn't say HTTP is asynchronous, although strictly it is,
based on the original and true definition of asynchronous communication.

And asynchronous I/O refers to non-blocking input/output processing,
and that is exactly what the RTI driver must support.
The driver can't block and needs to process other events from the RTI processor and from multiple device GUIs,
while asynchronously waiting for the responses from MCWS.
This is independent of whether HTTP itself is synchronous or asynchronous;
the driver should be transporttype-agnostic.
The objects and the underlying RTI driver runtime are supporting asynchronous programming style.

WebGizmo is also receiving the responses asynchronously from MCWS, BTW.

But the whole point of this thread,
is to suggest improvements in MCWS so that there is a reliable, consistent and simple way to identify and parse the MCWS responses.
It is good programming practice and design to provide and return distinct response types.
Having the function name in the response is just a simple suggestion,
and helps for parsing the response, you have to agree on that?

Handling different parameters for the same functions giving different information in the response,
is another similar problem with MCWS, IMHO.
MCWS should give enough information in the response
so that it is unambiguous and the context is given.

JRiver should also think ahead if they are going to provide an MCWS similar API
with push responses/notifications.
Then obviously you can't have two different events returning the exact same notification contents.

[MrC]

You are confused about some things.  

Async in your context means your requests do not block your main thread.  That doesn't absolve your client from the responsibility of performing proper HTTP protocol operations, namely that your app issues a request and it must wait for that response.  In your context, it means your request thread must setup its callback for the response and it must track the correlation between the request and response.

From RFC2616:

1.4 Overall Operation

   The HTTP protocol is a request/response protocol. A client sends a
   request to the server in the form of a request method, URI, and
   protocol version, followed by a MIME-like message containing request
   modifiers, client information, and possible body content over a
   connection with a server. The server responds with a status line,
   including the message's protocol version and a success or error code,
   followed by a MIME-like message containing server information, entity
   metainformation, and possible entity-body content. The relationship
   between HTTP and MIME is described in appendix 19.4.

and you are essentially pipelining:

8.1.2.2 Pipelining

   A client that supports persistent connections MAY "pipeline" its
   requests (i.e., send multiple requests without waiting for each
   response). A server MUST send its responses to those requests in the
   same order that the requests were received.

   Clients which assume persistent connections and pipeline immediately
   after connection establishment SHOULD be prepared to retry their
   connection if the first pipelined attempt fails. If a client does
   such a retry, it MUST NOT pipeline before it knows the connection is
   persistent. Clients MUST also be prepared to resend their requests if
   the server closes the connection before sending all of the
   corresponding responses.

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
   premature termination of the transport connection could lead to
   indeterminate results. A client wishing to send a non-idempotent
   request SHOULD wait to send that request until it has received the
   response status for the previous request.

but you say:

   Yes, the responses will return in the same order and sequence as the requests,
   but if there are communication problems, requests can get lost,
   and then I can't be sure which request the next OK response belongs to.

So you are pipelining, but not correctly dealing with the case of "communications problems", whereby you must restart the pipeline.  HTTP presumes a reliable connection.  You cannot presume that m responses out of n requests is good enough.  If you have "communications problems" and requests are lost, you are ignoring your responsibility as a client by not reissuing those requests and awaiting their responses, in accordance with the RFC2616.

[DSKO]

The RTI underlying runtime is already handling the low-level HTTP operations
the asynchronous callbacks and events from both RTI and the communication channels,
and takes care of requests and responses and the queueing and order of them.

The point is that if the MCWS protocol had defined distinct and better responses with context/correlating data,
parsing would be more reliable and simpler, AND one wouldn't need to worry about keeping track of the request and response order, IMHO.

[JimH]

I removed a couple of edgy comments from the last post.  Hendrik works for JRiver.  MrC is a dedicated user.  Both are knowledgeable and may be useful if you can be a little more patient.

[MrC]

I see your post changed from the notification email I received.  I do not work for JRiver and I do apologize for the tone.

I'll suggest that you strayed off course when you started to school Hendrik on the proper definition of asynchronous, and this can lead to push-back.

It appears that your RTI library is not providing a means for your tracking of request/response pairs, and that you'd prefer the server to do it for you via variations in replies.  I agree w/Hendrick on this one, for what its worth.

Again, sorry for any offense.