Subject:
|
Re: legOS Network Protocol
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 20 Apr 1999 11:45:19 GMT
|
Viewed:
|
1371 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Lou Sortman writes:
> Mike Moran wrote:
>
> > Anyway, I had a look around and I found some references on a protocol
> > layered on top of IP called RDP (Reliable Data Protocol). It provides
> > a message-based unreliable or reliable (toggled as necessary) service
> > on top of IP ie most of the advantages of TCP without all the guff.
>
> Sounds good. Does it provide a stream interface or datagrams only? My
> faulty memory suggests that it might be the latter. If the network
> implementation supports packet reassembly (packets larger than MTU), there
> may not be a need for a stream interface.
The interface is specifically datagram only. Dunno about packet reassembly;
I doubt it as the philosophy is minimalism. The main advantage I see in it
is the ability to change the degree of checking it does on your behalf to
ensure packets arrive. Btw, it may help to know that it was originally
designed to allow things like remote debugging of hardware devices ie lots
of short commands with the occasional memory dump.
[useful stuff about timers and addressing/ports deleted]
> > Anyway, who else is actively interested in this?
>
> Oh, I'm interested in the networking stuff, but I'm probably more helpful
> staying out of their way. I've got my hands full with the minutiae of signal
> implementation. I'd love to see more discussion of the networking stuff on
> the list.
>
> I'll eventually be tackling virtual timer issues when I try to implement the
> alarm() function. My needs will dictate that a signal be sent to a specified
> pid when the timer expires. What sort of interface will be required for the
> RDP timers? Polled? Callback? Signal? I might as well make it general
> enough for multiple uses.
From what I remember, the timers are only used to set off an alarm when
a packet hasn't been ACK'd. This would imply some sort of callback or signal
interface. I've still to think about how I would implement this but it may
make sense to have a timer callback which activates a single thread which is
responsible for quickly servicing whatever you have to do when the alarm goes
off. Like I said, I haven't finished reading the rfc, but I'll keep your
implementation questions in the back of my mind.
On a separate note, what are peoples thoughts on the low-level wireline
protocol? I ask because I want to know how it would be effected by, in a given
room, some robots talking via the legoOS native protocol, some using the lego
VM protocol, and some just using the IR as a sensor for proximity detection? I
would expect the IR-as-proximity-sensor traffic to be particularly bad since it
may be on all the time, deliberately trying to flood the region with light.
Maybe I'm bieng stupid, would this be a problem?
And finally.... Can legOS be set up in "simulation mode" ie running on a PC as
if it was on the RCX? This would make doing the networking code a lot easier as
all the stuff above the hardware layer could be designed and tested separately.
A simple (controllable and repeatable) simulation of the network including
latency and connectivity would make *everything* a lot easier. Even if it's not
possible I can still probably set up a self-contained box around my impl.
Anyway, that's my thoughts so far. If anyone is interested in joining in, I'll
keep note of any names that are emailed to me.
Thanks
Mike
|
|
Message has 3 Replies:
 | | Re: legOS Network Protocol
|
| (...) From what little I remember about the Lego protocol, here are some thoughts. *) On reception, some Lego packets may contain data which look like the beginning of a legOS native protocol frame. Most likely, the checksum would fail (once enough (...) (26 years ago, 20-Apr-99, to lugnet.robotics.rcx.legos)
| | | Re: legOS Network Protocol
|
| (...) Yes this will be a datagram only protocol for the time being. The LNP will allow us to do things like debugging and remote control. I have also invisioned something like a "shell" running on the legOS that you could either "telnet" in to or (...) (26 years ago, 20-Apr-99, to lugnet.robotics.rcx.legos)
| | | Re: legOS Network Protocol
|
| (...) Hmm.. with a little hacking you could certainly detect logic errors. The main problem I think would be writing alternative C-Functions for the H8 assembler, which makes up legOS itself. You'd also need to create a simulator engine for legOS to (...) (26 years ago, 21-Apr-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: legOS Network Protocol
|
| (...) Sounds good. Does it provide a stream interface or datagrams only? My faulty memory suggests that it might be the latter. If the network implementation supports packet reassembly (packets larger than MTU), there may not be a need for a stream (...) (26 years ago, 14-Apr-99, to lugnet.robotics.rcx.legos)
|
13 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
