Directory listing is a little different. It sends multiple messages back.
One for each directory entry plus one for a null stop. (and a potential nop
one in case the directory is taking too long).
The good part is that this lowers latency -- you can start processing
directory entries while more are being returned.
So the actual first message is 24+42 bytes long, then starts the second.
Size is the actual string length (there is a little extra allocated to allow
for some longer entries, which is why the payload is longer) If size=0 then
this is the NULL terminating message.
On return, the TYPE field is the return value, 0 is good.
One other thing, seen rarely. If it's taking too long to get a directory
element (longer than one second) a "ping" message is sent -- showing the
connection is still alive. The ping message has a payload of "-1" (but no
real payload). Otherwise after a couple of seconds of no response, assume
the worst.
Paul Alfille
On 12/5/06, Peter Kropf <[EMAIL PROTECTED]> wrote:
I was poking around the owserver protocol from Python to see if a
simple standalone python module can be created that doesn't have any
dependencies on the core ow libraries. I ran into a bit of a problem
with the protocol that's being used. Here's a hex dump of the data
that's returned when I request a directory of the root.
00000000: 0000 0000 0000 002a 0000 0000 0000 0102 .......*........
00000010: 0000 0005 0000 0000 6275 732e 3000 ec28 ........bus.0..(
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 002a 0000 0000 0000 .........*......
00000050: 0102 0000 0008 0000 0000 7365 7474 696e ..........settin
00000060: 6773 0000 0000 0000 0000 0000 0000 0000 gs..............
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 002a 0000 0000 ...........*....
00000090: 0000 0102 0000 0006 0000 0000 7379 7374 ............syst
000000a0: 656d 0000 0000 0000 0000 0000 0000 0000 em..............
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 002a 0000 .............*..
000000d0: 0000 0000 0102 0000 000a 0000 0000 7374 ..............st
000000e0: 6174 6973 7469 6373 0000 0000 0000 0000 atistics........
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 002a ...............*
00000110: 0000 0000 0000 0102 0000 0010 0000 0000 ................
00000120: 2f31 302e 4237 4236 3444 3030 3038 3030 /10.B7B64D000800
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 002a 0000 0000 0000 0102 0000 0010 0000 .*..............
00000160: 0000 2f32 362e 4146 3245 3135 3030 3030 ../26.AF2E150000
00000170: 3030 0000 0000 0000 0000 0000 0000 0000 00..............
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 002a 0000 0000 0000 0102 0000 0010 ...*............
000001a0: 0000 0000 2f38 312e 4134 3443 3233 3030 ..../81.A44C2300
000001b0: 3030 3030 0000 0000 0000 0000 0000 0000 0000............
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0102 0000 ................
000001e0: 0000 0000 c002 ......
It shows (hex - decimal):
version: 0x0 - 0
payload length: 0x2a - 42
type: 0x0 - 0
format flags: 0x102 - 258
size of data: 0x5 - 5
offset - 0x0 - 0
The payload doesn't look quite right since there's a whole lot more
that's received from the server, 486 bytes total. The size of data
seems to correspond to the length of the first entry name w/ trailing
null - bus.0. But the rest doesn't make much sense to me. In looking
at the hex dump of the data, I see the various values that I would
expect in settings, system, statistics, etc. But I also see a whole
lot more data that seems to be extra.
I tried reading through the C headers and source but had trouble
making heads or tails of the code that would be putting the buffer
together to send over the network. I'm a wee bit lost here. So if
anyone has a good idea of what's going on, let me know.
Thanks!
- Peter
On 12/4/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
> Ok, communication is via tcp.
>
> 1. open port
> 2. send a message
> 3. wait for response (single response except for directories).
> 4. close port
>
> Message has format:
> 6 words (24 bytes) fixed header
> variable length "payload"
> Words must be sent in network order (bigendian I believe)
> Header is:
> Version (use 0)
> Payload (size of variable length in bytes)
> Type (see below)
> SG (basically temperature scale)
> Size (for writes, size of data portion of payload)
> Offset (for reads and writes, usually 0)
> Type
> 0 error
> 1 nop
> 2 read
> 3 write
> 4 dir
> 5 size (not used any more)
> 6 presence
>
> Basically, you set up the header, and follow it with payload, and send
the
> whole thing.
> Payload is typically the "path" e.g. /10.12300432433/temperature
> Possibly followed with a value for writes.
>
> You get back about the same thing. The fields are slightly different
(error
> codes, data length) but the value is in the payload.
>
> If you want to do this, I'm sure people would be glad to assist. It
> certainly sounds like an interesting project.
>
> Paul Alfille
>
>
>
> On 12/4/06, chris <[EMAIL PROTECTED]> wrote:
> > On Monday 04 December 2006 12:02, Paul Alfille wrote:
> > > On 12/4/06, chris <[EMAIL PROTECTED]> wrote:
> > > > I understand that owfs is unlikely to run on windows but is it
> possible
> > > > to tun
> > >
> > > Au-contraire! (Though the windows port is not yet of the same
quality.
> > > There have been reports of memory leaks that need to be
investigated).
> > >
> > > owpython on a windows box connected to owserver without resorting
to
> > >
> > >
> > > Ahh! You want to communicate (with owserver?) via python, but not
use
> the
> > > libow library (which builds under cygwin).
> > > This has been done for other languages:
> > >
> > > owshell -- uses C to talk to the owserver directly. Perhaps a little
> > > complex, since it includes the Bonjour code and came from a stripped
> > > version of libow in the first place.
> > >
> > > owsim -- a work in progress that uses Tcl to talk to owserver. Tcl
has
> > > great network support and we essentially parse the owserver protocol
in
> Tcl
> > > code.
> > >
> > > I suspect that you could do the same in python. Probably a few days
> project
> > > for a python expert. The owserver network protocol is documented on
the
> > > website:
> http://www.owfs.org/index.php?page=owserver-protocol
> > > (And in the code, of course).
> > >
> > > For TCL
> > > network basics:
> > >
>
http://owfs.cvs.sourceforge.net/owfs/owfs/module/simulants/ownet.tcl?revisi
> > >on=1.5&view=markup server code:
> > >
>
http://owfs.cvs.sourceforge.net/owfs/owfs/module/simulants/owhandler.tcl?re
> > >vision=1.8&view=markup (Note that owsim is a owserver, rather than
> client).
> > >
> > > excellent but rather cumbersome methods like cygwin?
> > >
> >
> > Yep that is the sort of line I'd like to be able to take. I'm very
messy
> at
> > code, but where's theres a will, I'm building a higher object model
using
> > Django http://www.djangoproject.com which constructs database models
from
> > python class models.
> >
> >
> >
> > > > I am keen to be able to monitor the one wire network in several
places
> > > > all of
> > > > which are windows devices with users who are even more simplistic
than
> > > > myself
> > > > ( if that can be believed, my only defence is that some of them
are 6
> > > > years
> > > > old)
> > >
> > > You underestimate your progeny! If they can hack python, they are
> probably
> > > os agnostic.
> >
> > They mostly use it to cheat on maths homework. Niether have realised
> > multiplication is a lookup.
> >
> > >
> > > owpython seems only to be availabe as an rpm, can I just copy the
source
> > >
> > I really don't want to have to re-write too much cos I'm lazy, and the
> more I
> > write the more errors I know are there.
> >
> > A Sensor object is a lovely concept in itself.
> >
> >
> > > I presume you want to display (and perhaps control) your system on
> > > distributed computers, with more than one platform. Have you
considered
> > > building a web app? Your cgi code can use python or bash or
whatever.
> You
> > > can expose whatever you want, even full owhttpd. It would be easier
to
> > > develope and use a central http server, trusting that all other
machines
> > > can easily load a browser.
> >
> > There's an attempt to generate a distributed model for community
energy
> use
> > monitoring that's running out of a forum:
> > http://navitron.org.uk/forum/index.php?topic=678.0
> >
> > I'm keen to plug into Visual Python for object representations of
solar
> rigs.
> > have a look at http://www.spritenote.co.uk/solar.html for
> an idea of what I'm
> > up to.
> > I've got a pretty awful object model running which might allow auto
> assembly
> > of this sort of system.
> >
> >
> >
> >
> > > Besides, we believe in cultural diversity.
> > > And we have great sympathy for non-native American speakers.
> > >
> > > Paul Alfille
> >
> > Hadn't considered the language implications of the style. And isn't
the
> > language English :D.. or is it actually written in Navaho?
> >
> >
>
-------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
share
> your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
>
>
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
