Open source networking Projects

[mfidelman@meetinghouse.net (Miles Fidelman)]

michi1 at michaelblizek.twilightparadox.com wrote:
> Hi!
>
> On 21:03 Thu 28 Nov     , Miles Fidelman wrote:
>> michi1 at michaelblizek.twilightparadox.com wrote:
>>> Hi!
>>>
>>> On 18:15 Tue 26 Nov     , Robert Clove wrote:
>>>> I am a new (sort of fresher) and want to do some work in networking domain
>>>> like network device driver or some changes that increase the network
>>>> performance and all.
>>>>
>>>> Could you please suggest me some projects if they are new it would be good
>>>> and easy to understand.
>>> I am programing a layer 3+4 network protocol for mesh networks. Take a look at
>>> http://michaelblizek.twilightparadox.com . I would especially like to see
>>> somebody improve the user space routing daemon (in the corutils repository).
>>>
>>>
>> Isn't this just a bit of putting the cart before the horse?  There's
>> nothing there that looks like a design document, architecture, or
>> protocol spec - it seems a bit early to think about coding a routing daemon.
> Well, the website is pretty much a design document. The protocol is partially
> documented on the website too and you can find more details if you open the
> net/cor/cor.h file. Also, if there is something you want to know, feel free to
> ask. I try to keep the docs readable by not adding too much irrelevant stuff
> and without feedback it is hard to know whether something is relevant or not.
>
>
I'm really not trying to be difficult here, but earlier in my career, I 
sat in a LOT of design review meetings associated with protocol design 
and implementation (back in the days when DARPA and NSF funded new 
protocols, and my colleagues at BBN wrote a lot of those protocols.

If someone asked for a preliminary design review - say as part of 
preparing a funding proposal, or before launching into software 
development - and presented what you have on your web site - my reaction 
would be that you haven't done your homework.

Not for nothing, but a design document tends to include things like:
- general motivation and context
- requirements being addressed
- technical approach, and the tradeoffs that went into it
- concept of operations

And for a protocol, things like:
- system architecture
- packet formats
- protocol operations
- state-machine transitions

Since you say that "Layer 4 might look similar to SCTP 
<http://en.wikipedia.org/wiki/Stream_Control_Transport_protocol>" I'll 
simply point to RFC2960 as the kind of documentation I'd tend to expect 
before delving into specific implementations.  Without that, it's kind 
of hard to tell what you're trying to do, why, and whether it's worth 
the effort to dig in and read code.

Beyond that, why are you asking for help on kernelnewbies - what does 
the code internals of a prototype protocol have to do with the linux 
kernal?  Seems like an odd place to be asking for support on protocol 
related issues (be it about protocol design or implementation).

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra