openidap-devel

[OpenIDAP-devel] Meeting

[Phil B. <ph...@pe...>]

We are planning to have another meeting to discuss the specifications tomorrow, Thursday Feb. 17.  Here at W.

Phil

[OpenIDAP-devel] Some Thoughts

[Phil B. <ph...@pe...>]

I've been thinking a little bit about the details of the protocol.  I like the idea of opening up multiple sockets for different aspects of the protocol.  For instance, having a TCP socket open between two nodes for session protocol.  (Similar to the way that SIP works for VoIP, or the way that FTP works)  This socket would have some kind of ASCII protocol similar to HTTP or SIP that would allow the two endpoints to deal with the details of the rest of the communication.

The ASCII protocol allows for easy debugging.  Then if the nodes decided to simply have a polling response type conversation (because that was the limit of one ends capabilities) then that conversation would be binary and take place through a different socket.  It might even be possible to have all the communication take place through this one socket (perhaps that is the only thing that the serial port communications could do.)

Asynchronous data change type events could be negotiated on another socket, historical data on another and multicast producer / consumer traffic on another.  OpenDAX has multiple sockets for different types of data and it makes the programming easier.

The ports should be known in advance (in lieu of being negotiated like FTP) so that firewall configuration, tunneling and port forwarding aren't too complex.

What do you guys think?

Phil

[OpenIDAP-devel] Status

[Phil B. <ph...@pe...>]

So far we have had two meetings and have gotten pretty far in discussing what we want the protocol to look like.  Some of the general features are...

The only dependencies should be a serial port or a TCP/IP stack.
Producer / consumer protocol with consumer initiated subscriptions for individual points of data
Multiple capability with handshaking to determine the "dumbest" node and adjust accordingly
Non-deterministic


Mandatory capabilities...

Array based data
Time to live for subscriptions that must be renewed by the consumer
Out of Band communications for IP based networks (simulated with serial ports)

Optional Capabilities...

Tag name based data
Use multicast to save on bandwidth
Historical data retrieval
Structured Data (i.e. User defined data types in ControlLogix)
Tag Metadata available such as engineering units, description, etc.
Event based communication

This list is by no means exhaustive and will surely change as we go.

We have not written any code yet but I did put a skeleton in the Subversion repository on the SourceForge Project page.  it uses the Autotools package for maintaining the build environment.  Right now it builds a couple of "Hello World" programs but it should make for a decent starting place.

There is also a skeleton of a LaTeX based specification document in the Subversion repository that we probably need to start working on.

One of the best ways to document this process is by asking/answering questions on this mailing list and letting the archive store that data.  Once a consensus has been met then we can put it in the spec and write some test code, then repeat and adjust.