Subject:
|
Re: LNP Addressing Schemes
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Thu, 3 Feb 2000 10:51:30 GMT
|
Viewed:
|
2889 times
|
| |
|
|
Les Smithson wrote:
> Addressing:
> . How does the addressing scheme work?
It's quite simple: Currently, there are two kinds of LNP-Packets: the
first one is called the integrity packet (switch your mail-reader to
fixed font now):
+--+---+-----------------------+---+
|F0|LEN| IDATA |CHK|
+--+---+-----------------------+---+
F0 : identifies an integrity packet
LEN : length of IDATA section, 0 to 255
IDATA : payload data
CHK : checksum
because LEN is one byte, DATA can be at most 255 byte, so the overall
maximum length of an LNP Packet ist 258 bytes. The Integrity packet does
not carry any addressing information, you could consider it as the LNP
broadcast mechanism.
The 2.nd kind of packet is the addressing packet. Actually, it is an
integrity packet that encapsulates payload data and addressing
information in the IDATA section:
+--+---+----+---+--------------+---+
|F1|LEN|DEST|SRC| ADATA |CHK|
+--+---+----+---+--------------+---+
| |
|<- IDATA ->|
F1 : identifies an addressing packet
LEN : length of IDATA section ( 1 to 255 bytes )
DEST : destination address
SRC : source address
ADATA : payload data (1 to 253 bytes)
Generally, LNP-addressing packets give you functionality quite similar
to UDP: they are not guaranteed to arrive, but if they arrive, they will
contain no errors. An addressing packet is always send to a specific
port on a specific host. If the host has started a server on this port
(an addressing-handler in LNP-idiom), and the packet arrives without
errors, the packet is passed to the handler, otherwise (no handler or
errors), the packet is silently discarded.
DEST and SRC carry the destination address respectively the originating
address of the packet. Both are 1 byte, which is split into a host and a
port section. The macro CONF_LNP_HOSTMASK (config.h) determines, which
individual bits of this byte are carrying host address information, and
which carry port information.
This gives you the option to configure the addressing scheme according
to your needs. E.g, if you had only 2 hosts ( a PC and a RCX ), but
wanted to have 128 distinguishable ports on each host, you could set
CONF_LNP_HOSTMASK to 0x80.
Actually, it is not neccessary to use bit-schemes like 10000000,
11000000, 11100000, ... for CONF_LNP_HOSTMASK, but it is wise to do so
!, because otherwise precious RAM will be wasted inside LNP.
Anyways, for most stituations the default CONF_LNP_HOSTMASK of 0xF0 will
be a good choice. With this setup, the upper 4 bit of DEST and SRC are
the host address, and the lower 4 bit denote the port. Thus, this allows
you to assign 16 different hostaddresses, and have 16 different ports on
each host.
> . Can a RCX address more than one host (via its Tower), and more than
> one program on a particular host?
As said above, with default CONF_LNP_HOSTMASK you can address up to 15
remote Hosts, and 16 ports on each of this hosts. Several ports can be
opened in one application or in several applications, it's just a matter
of taste.
> . How does the RCX side set the source & destination addresses?
The source-hostaddress for the RCX is set when compiling legOS by macro
CONF_LNP_HOSTADDR (boot/config.h). By default, it is 0x00. If you want
another hostaddress for your RCX, you have to change this macro and
recompile legOS. Remember, the upper four bits form the hostaddress!
Thus, to yield hostaddress 1 you would have to specify 0x10, NOT 0x01.
Thus, to have several RCX's have different hostaddresses, you must
compile abd doenload legOS several times, changing the CONF_LNP_HOSTADDR
inbetween.
The destination address (HOST/PORT) is specified as parameter to
lnp-addressing_write().
You specify the destination for every packet sent in the call of this
function.
> . Can a Host address more than one RCX?
Same as above. The semantics of lnp_addressing_write(),
lnp_addressing_set_handler(), etc. is exactly the same on PC and RCX.
> . Can the host set its source address? If so, how?
Before you continue, i'd encourage you to open file liblnp.h from the
lnpd tarball and look at the prototype for lnp_init().
As described in the header file, the hostaddress and mask may be set in
the call to lnp_init(). If you use 0, the defaults, means 0x80 and 0xF0
are used.
With liblnp, you can set an arbitrary hostaddress and hostmask inside
each application you run. If you use the same hostaddress in 2 or more
applications running concurrently, and have setup a handler for the same
port in this applications, every incoming packet for this host/port will
be delivered to each application, means, the packet is multiplied ( lnpd
realises this ).
IMHO, normally you don't want this. I suggest to use 1 hostaddress for
every PC involved in communications (there may be several, lnpd is fully
networked), and use different port numbers in different applications
running on the same PC.
However, it's perfectly legal to use different hostaddresses in
different applications running on the same PC.
In contrast, it's NOT OK to have different HOSTMASKs. Therefore, the
default hostmask used by liblnp is 0xF0, the same as the default for the
RCX. If you want to use another HOSTMASK, you have to do this on all
RCX's (recompile legOS) and all PC-applications that are involved (set
in lnp_init).
> Transmission:
> . Is there a way to send reliable, sequenced data, like TCP does?
Currently not, but i'm nearly finished with an implementation of this
(it quickly gets more complicated than one might think at the first
glance). The RCX-side is already done, but i have only one RCX, so i
can't test it. Because i'm quite busy at the moment, it may take about 4
weeks before the PC side counterpart will be available and tested.
> Host Programming:
> . Is there a way to write simple programs on the host side that don't
> need to go through the lnpd demon?
Actually, the development goal of lnpd was to make application
programming simple ;-).
If you want to write applications that don't rely on lnpd, you have to
do all the tower related stuff (configure tty, wakeup, send keepalive),
and packet processing inside your application - an example of how to do
this is the 'original' dll that comes with legOS.
Of course, one could wrap all this into a library. Once i find the time,
i'll try to pick up the various fragments of code from my trash-folder
and build that beast, but that might take some time...
> And finally, is the LNP protocol documented? If so, where can I get a
> copy?
hmm, the best documentation i know about is this message ;-(, but i'm
quite sure Markus' upcoming book published by O'Reilly will cover that
in more detail.
hope that helps a little, Martin
|
|
Message is in Reply To:
 | | LNP Addressing Schemes
|
| I have the basic Linux<->RCX Infra-red comms. working using lnp calls on the RCX and Martin Cornelius' lnpd on the Linux end. I have a few questions about this: Addressing: . How does the addressing scheme work? . Can a RCX address more than one (...) (25 years ago, 2-Feb-00, to lugnet.robotics.rcx.legos)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
