Open source networking Projects
Miles Fidelman
mfidelman at meetinghouse.net
Fri Nov 29 12:14:42 EST 2013
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
More information about the Kernelnewbies
mailing list