[openbeosnetteam] Re: A possible redesign

The more I follow this redesign thread the more I'm getting feeling that I have 
seen something similar.
Basically, there are 2 implementations of TCP/IP in Unix world - sockets in BSD 
and streams in System V.
This proposal looks more like streams approach. We could add a BeOS twist to it 
- use BFS attributes. If we create a node in BFS something like /dev/net/tcp 
then we could use node atttributes to pass information to user-land 
applications - of course it doesn't mean we have to read and write it to disk. 
Then of course, it would be more tied to VFS part of kernel and translators 
would be more like filesystem plugins. ioctl comes there naturally. ifconfig 
would be obsolete - just change attributes of /dev/net/ip/<instance_number> 
device file. VFS is said to be 90% done, but I haven't look in sources to see 
how well complicated implementation could be. May be Axel would drop his 
thoughts about netfs filesystem plugin.

vlad
--

On Sat, 19 Apr 2003 11:05:36  
 Nathan Whitehorn wrote:
>> > > Yes, if we use int32s and specify (like in BMessage:what) which 
>> > > id
>> > > belongs
>> > > to which attribute it could be quite fast.
>> > > This might lead to collisions. How is this prevented? By 
>> > > specifying
>> > > the
>> > > module when asking for attributes?
>> >
>> > Luck? :P We could demand prefixes, for example, like ethernet
>> > attributes have ids beginning with 'EN'. BMessage what attributes 
>> > don't
>> > often suffer name collisions, as you mentioned. You could also have
>> > only the attributes from the last network layer attached, thus
>> > eliminating the chance of collisions entirely. Also, as much header
>> > information in many protocols (like PPPoE) is set up as a key/value
>> > structure with integer keys, you could just place that data 
>> > straight
>> > into attributes.
>> 
>> Are attributes references to positions in the packet or copies of the 
>> data?
>
>It could be both or either.
>
>> Do you specify their length?
>
>Probably.
>
>> Doesn't this reference eat up more memory than the entry itself? I 
>> think
>> this is too slow.
>
>It might well be slow. But with integer handles and references into the 
>stream, it might not be much slower than now, especially when many 
>packets get parsed multiple times. 
>
>> > > You mean that IP does not have to know anything about Ethernet
>> > > broadcasting
>> > > because the translator knows it?
>> >
>> > Right. In fact, the IP addon wouldn't need to know anything about
>> > ethernet at all, because the translator handles that.
>> 
>> I like this concept, really. The next netstack should implement this.
>
>Thanks.
>
>> > > Are the attributes exported to user-level? Does the BSD-
>> > > compatibility
>> > > layer
>> > > translate our attributes into structures?
>> >
>> > I don't see why they would be. The user really has no reason to 
>> > care,
>> > and for things like TCP, packet-based attributes don't make much 
>> > sense,
>> > since the system isn't packet-based.
>> 
>> With user-level I mean the normal application level (not kernel-
>> level). It
>> is for the programmer who needs access to those attributes. The user 
>> should
>> not be interested in it, but are these attributes usable only by 
>> kernel
>> modules or by application, too?
>
>Right, and by "user" I meant the calling application. Since TCP is a 
>stream-oriented interface, packet attributes make little sense to 
>transmit. They might make more sense with UDP (conceptually), but I 
>can't think of any real benefit of knowing them either. Perhaps we 
>could have an optional interface to retrieve them.
> 
>> > > How do you want to implement this exactly? An HTML presentation 
>> > > would
>> > > be
>> > > useful. ;)
>> >
>> > That might actually involve work :P. What questions would have in
>> > regards to the implementation?
>> 
>> You do not have to do it, but it would be nice. Just start from the
>> beginning. ;)
>> What are you currently working on? Maybe this should be done when R1 
>> has
>> been released because we need a basis before doing something else.
>
>I'm currently working on school, and have been fiddling with the kernel 
>to try to get it running on PowerPC, which because it involves 
>installing Linux (to get a gcc that outputs ELF) has been 
>extraordinarily difficult with very little reward. But yeah, I could 
>try setting up a tiny reference implementation of this kind of stack.
>-Nathan
>
>
>--
>Fortune Cookie Says:
>
>Go placidly amid the noise and waste, and remember what value there may
>be in owning a piece thereof.
>               -- National Lampoon, "Deteriorata"
>
>


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

Other related posts: