| |
I thought it might be good to repost this with some changes...
Okay a little smaller... Only a 4 byte header...
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
-----------------------------------------------------------------
| 0xF | VER | TOADDR | PORT| FRADDR | PORT| PAYLOADLEN |
-----------------------------------------------------------------
/ PAYLOAD /
-----------------------------------------------------------------
/ PAYLOAD / CRC16 |
-----------------------------------------------------------------
0-3: The first nibble with help the OS understand that this incoming
data is
the LNP protocol.
4-5: The version number of the protocol we are using. Only gives us 16
tries to get it right...
8-15 & 16-23: To Address and From Address are 5 bits each. This allows
for 32 addressable nodes. The address 00000b will be used for
broadcasting. The other 31 assigned to the RCXs and Towers. The ports
are 3 bits each giving a range of 0-7. Port 0 reserved for the OS.
Maybe in theory we could route this protocol over IP between to sites.
It was suggested by some to make this larger or to support host masking,
but I feel that the complexity added is overkill for the legos. If you
have more than 32, realisticly about 12, legos in a room trying to talk
you are going to have so much IR flooding and collisions that
communication will fail. Limiting the addresses to 32 devices is more
than enough to accomplish a large task.
24-31: Length of the payload from 0 - 255. This of course is way too
large. Realisticly anything over about 63 bytes is just asking for a
transimition failure. You are better off sending lots of smaller
packets. We could then use the remaining bits as some sort of flags.
The number 63 only requires 6 bits, so that gives us 2 extra for flags
or some other value 0-3. One idea that comes to mind is bit 0 and 1 are
device identifiers. The value 0 is a lego and the value 1 is a tower or
pc. Might be useful?
32-32+PAYLOADLEN: Payload max is 255 bytes. More realisticly 63.
32+PAYLOADLEN-32+PAYLOADLEN+16: CRC16 was an idea thrown out as a
solution. Might be overkill?
So what do you all think...
-Jake
|
|
Message has 5 Replies:
 | | Re: LNP Repost
|
| (...) I can see this. but it is starting to feel a little cramped on the ports, though. What functionality is port 0 reserved for? Actually, I was thinking of reserving a host address (such as 0x0) for IPC. I'd probably want to have more than 3 (...) (26 years ago, 16-Apr-99, to lugnet.robotics.rcx.legos)
| | | Re: LNP Repost
|
| (...) I'd prefer 11111b for broadcast, in keeping with TCP/IP. Cheers, Ben. -- (URL) grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was (...) (26 years ago, 17-Apr-99, to lugnet.robotics.rcx.legos)
| | | Re: LNP Repost
|
| (...) Actually, no. On attempt 16, you reserve some more bits further down for the new version number :-) Cheers, Ben. -- (URL) grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to (...) (26 years ago, 17-Apr-99, to lugnet.robotics.rcx.legos)
| | | Re: LNP Repost
|
| Hi, I'm kinda new to LUGNET, so if I get this wrong - sorry! I'm interested in this LNP idea that seemed to be floating around a few months ago. Is it still alive, and if so what state has it got to? I would be grateful if someone can post or e-mail (...) (25 years ago, 27-Jul-99, to lugnet.robotics.rcx.legos)
| | | Re: LNP Repost
|
| (...) My only thoughts are that not everybody will need or want the generality of port support in the protocol. I would suggest reordering the first four bytes, moving the payload length up toward the front, and defining it to explicitly include the (...) (25 years ago, 28-Jul-99, to lugnet.robotics.rcx.legos)
|
21 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
