Subscribing model in XPCA

[flipback]

Hi, folks!

I'm working on asynchronous request in XPCA now. It will to implement a subscribing model for given data by change. I see 2 way for resolved this task:

1. Long polling;
2. Webscokets.

Long polling


    SERVER                                 CLIENT
      |                                       |<------- subscribe('xpca.org/point1', func)
      | <----- http://xpca.org/point1 --------|
    (wait change)                             |
      | -----------{'value': 0.0}------------>|
      |                                       |--------> callback func(value)
      | <----- http://xpca.org/point1 --------|
    (wait change)                             |    
      | -----------{'value': 1.0}------------>|
      |                                       |--------> callback func(value)
      

This model is easy and require only webserver with support asynchronous. But it has some defects:

- Asynchronous request has a timeout for idle;
- If changes is very intensive largest part of traffic is expended on HTTP headers;
- Every subscribers use separate socket that limited theirs quantity;
- It need a difference syntax for synchronous (current data) and asynchronous (changes data) requests. For example:
    * For current data  http://xpca.org/point1
    * For data by change http://xpca.org/point1&by_change=true

Webscokets

     SERVER                                CLIENT
      |                                       |<------- subscribe('xpca.org/point1', func)
      | <----- ws://xpca.org/point1 ----------|
 (open socket)                         (open socket)
      | -----------{'value': 0.0}------------>|
      |                                       |--------> callback func(value)    
 (wait change)                                |    
      | -----------{'value': 1.0}------------>|
      |                                       |--------> callback func(value)

Websocket is upgrade HTTP protocol for directly messages between server and client. After receiving request starting with 'ws://' server open websocket connection with client, which use as simple TCP socket. Quality this model:

+ Websocket may be without timeouts;
+ Traffics is not expended on HTTP headers;
+ Single syntax for current data and changes;

Defects:

- Every websocket  use separate socket that limited theirs quantity;


Well, Webscokets is looked very likely, but limit of connections does this implementation is risque. This limitation may slide over with multiplexing of every websocket in one connection.
Now Websockets don't support automation multiplexing (http://stackoverflow.com/questions/6209358/websockets-do-they-shared-the-connection) but this problem can resolved on application layer.


     SERVER                                CLIENT    
      | <----- ws://xpca.org/webscoket--------|
  (open socket)                        (open socket)
      |                                       |
      |                                       |<------- subscribe(xpca.org/point1, func1)
      | <----- {'subscribe' : 'point1 }-------|
      |                                       |<------- subscribe(xpca.org/point2, func2)
      | <----- {'subscribe' : 'point2 }-------|
      |                                       |
      | -------{'point1' : {value: 0.0}------>|
      |                                       |--------> callback func1(value)    
      | -------{'point2' : {value: 1.0}------>|
      |                                       |--------> callback func2(value)

What do you think about it? May be some ideas still?

Thanks
Aleksey Timin

[Darren]

I'd be inclined to go with WebSockets. Its basically the way I've done
it before but using traditional tcp sockets.

Another protocol we might want to think about is atompub. I don't know
too much about this protocol, specifically in area of handling
frequent updates. Maybe its a case of using WebSockets for important
information that has to be notified as soon as it changes and atompub
for slower changing data.

I know Tom has thought about this a bit.

Darren

>     * For data by changehttp://xpca.org/point1&by_change=true

>
> Webscokets
>
>      SERVER                                CLIENT
>       |                                       |<-------
> subscribe('xpca.org/point1', func)
>       | <----- ws://xpca.org/point1 ----------|
>  (open socket)                         (open socket)
>       | -----------{'value': 0.0}------------>|
>       |                                       |--------> callback
> func(value)    
>  (wait change)                                |    
>       | -----------{'value': 1.0}------------>|
>       |                                       |--------> callback
> func(value)
>
> Websocket is upgrade HTTP protocol for directly messages between server and
> client. After receiving request starting with 'ws://' server open websocket
> connection with client, which use as simple TCP socket. Quality this model:
>
> + Websocket may be without timeouts;
> + Traffics is not expended on HTTP headers;
> + Single syntax for current data and changes;
>
> Defects:
>
> - Every websocket  use separate socket that limited theirs quantity;
>
> Well, Webscokets is looked very likely, but limit of connections does this
> implementation is risque. This limitation may slide over with multiplexing
> of every websocket in one connection.

> Now Websockets don't support automation multiplexing (http://stackoverflow.com/questions/6209358/websockets-do-they-shared-...)

[Tom Tuddenham]

AtomPub might be slightly heavy weight. Bizzare to contemplate this -
in comparison to SOAP - but in very constrained devices this may be
true. My initial thinking was around using webhooks, but that idea
seems to have died a sad death - webhooks.org has nothing of value and
even the wikipedia article has been deleted.

Both AtomPub and Websockets fit in with XPCA's general RESTful
architecture, though they really cater for different needs. Websockets
are probably more useful in real-time contexts (e.g. low-latency HMI
interfaces) and AtomPub is better suited to displaying historical
data.

My inclination would be to do both, as the more connections that are
available to XPCA the more likely it will be adopted by interested
parties.

One crazy idea that's still floating around in my head is this notion
of "recipes". If we describe a recipe, say "Using XPCA with
Websockets" and another "Accessing XPCA via AtomPP" (and "Mapping
MODBUS to XPCA" and so on). If each recipe is identified then it's a
matter of interrogating the service to see what you can do with it.
This concept is all very loose, but the general idea is that rather
than insist on one way of doing things, providing a number of possible
ways and let people figure out what best suits them. I'll have more on
this later, in another post.

But back to Websockets vs, AtomPub, I think both your ideas are sound.
We just need to work the details out. From then on it's just a simple
matter of implementation :)

Cheers
Tom

[ferrisoxide]

It looks like marshalling calls back and forth via websockets isn't
too difficult. I haven't played with it but from what I read it looks
like maintaining one connection per client is possible.

Typically you're not going to have hundreds of clients per device -
probably only 1 or 2 - so I don't see the overhead of TCP connections
being too much of a burden. If you spread the load, using Websockets
for low-latency data and Atom or direct HTTP polling for the other a
single small server should be able to handle a number of clients.

Stuff to think about.

[flipback]

The problem lies in the fact that websocket is needed for each subscribed resource(really tag). In this context, limit of quantity sockets is important. Resolve is a multiplexing and implementation channels for everyone subscriber on application layer in one websocket connection for one client. That is possible, but It some complicate implementation.

[flipback]

Also, implementation of subscribers into single websocket will require presence of internal protocol subscribing
For example:

client: Send HTTP request GET ws:\192.168.0.1\subcriber
server: Open websocket connection with client
client: Send to websocket { 'subcribe' :{  'resource' : 'path_resource', 'deadband' : 0.4, .... }  } for subscribing to changes
server: Create subscribe
server: Send to websocket { 'event' : { 'resource' : 'path_resource', 'value' : 232,2, 'timestamp' : '2011-07-21 23:23', ... } } after changing data

something like this....

[ferrisoxide]

I think Darren has done something similar with multiplexing data over
TCP. He talks about the concept of a "faceplate" - a collection of
states for a particular machine, group of machines or a process. Your
websocket could be connected to single faceplate which then has the
job of demarshalling the data that comes back. If we have a common tag
model then one socket could manage a whole stack of resources - with
faceplates used as a mechanism to bundle access to a group of tags
together.

Maybe we're trying to solve a problem that doesn't exist yet. Let's
get websockets working with a simple server and then look at
implementing faceplates on top of that?

Cheers
Tom

[Aleksey Timin]

https://gist.github.com/5837a3f7031a4c8a5bd1

This example is XPCA server with websocket. It is showing a
subscriptions on changing points.
Sorry, I could not have a stable working code - not all sockets open
with success. But It is demonstrating the principle.
Each point have a separate websocket that is problem. If I understand
you correctly, we could to bundle many point in group and use the same
methods.
I not sure that it is best way, but I not sure that not)

Now I am designing the XPCA server for communicate with device and OPC
servers. First priority is implementation synchronous read\write
operationы and I sure we will return to this problem with new
understanding;)

Aleksey

2011/8/13 ferrisoxide <ferri...@gmail.com>:

[Darren]

Connecting to single points to monitor changes quickly becomes
impractical for larger systems, too many scarce resources are used ie
network connections. What we did to fix this issue was to arrange the
data in the device into sections or groups of related data. For
instanace all the points for a physical machine would be grouped into
a contiguous area within in the PLC memory, ideally not more than a
maximum modbus read allowed under the protocol. Our server would read
these chunks of memory and if there were changes and a client had
registered for that area the server would send the changes. The client
would look at the data and determine which bytes had changed and fire
events for individual points on the client side. This does mean that
the client side has to have the smarts to be able to raise events but
I believe this is possible with the current state of javascript and is
something I'm looking at.

In XPCA terms a machine resource say http://device.mycompany.com/objects/boiler/1
would return a json or xoxo representation of boiler1 that contains
all the related data points. A subscription to this resource could be
created that would return the entire representation and then
processing by the client could determine which points had changed in
the resource.

This does raise the questions of how do we define the objects within
XPCA, perhaps that should be out next area to tackle.

On Aug 13, 7:57 pm, Aleksey Timin <ati...@gmail.com> wrote:
> https://gist.github.com/5837a3f7031a4c8a5bd1
>
> This example is XPCA server with websocket. It is showing a
> subscriptions on changing points.
> Sorry, I could not have a stable working code - not all sockets open
> with success. But It is demonstrating the principle.
> Each point have a separate websocket that is problem. If I understand
> you correctly, we could to bundle many point in group and use the same
> methods.
> I not sure that it is best way, but I not sure that not)
>
> Now I am designing the XPCA server for communicate with device and OPC
> servers. First priority is implementation synchronous read\write
> operationы and I sure we will return to this problem with new
> understanding;)
>
> Aleksey
>

> 2011/8/13 ferrisoxide <ferrisox...@gmail.com>:

[Aleksey Timin]

Thanks, Darren)

Finally, I have understood that Tom and you mean! It's more higher
level of abstraction
for mapping and subscripting data. You open my eyes)))

2011/8/16 Darren <dj.da...@gmail.com>: