Topic: Developers' Journal

[whitelynx]

I'm starting this thread as a collection of random thoughts and questions I come up with as I go through the process of converting the old HawkNL code into RaptorNL's new structure. Anyone should feel free to reply if they have any thoughts on what I say here. (also, contingencplan, feel free to post your own thoughts and questions here as well) I'd like to turn this into a running discussion of the structure of RaptorNL. If any one question in this thread grows beyond a couple of posts, it will get moved to its own thread.

[whitelynx]

First, some questions I've already posed to contingencyplan and others in the Precursors IRC channel, just in case any forumites have thoughts on them:

• Where should we use references vs. pointers? So far the consensus seems to be that we should use references for the Address class at least so that we can test for equality without dereferencing pointers. Otherwise you get ugliness: ((*add1) == (*add2)) See the articles at http://www.embedded.com/story/OEG20010311S0024 and http://www.parashift.com/c++-faq-lite/references.html for more information on the subject.
• Should a Buffer class be made to encapsulate all the read/write macros in raptornl.h? Currently we have HawkNL's read and write macros for every data type, made for working with packet buffers. (arrays of bytes) I think it'd make sense to use a class for this so that the user doesn't need to work with raw buffers.
• Where should endian-swapping go? I think it'd make sense to put it in the Buffer class, but then you're required to use it for all data... on the other hand, this isn't necessarily a bad thing. (we'd just use a Buffer* or Buffer& in all our send/receive functions)
• Should we make a class for the overall network layer options? There are some "global" options like whether or not to collect socket statistics, big vs. little endian data, and allowing multiple drivers to be selected... I'm not sure how many of these options will stick around once we've finished the conversion, but it might still be nice to have a central place to manage the various sockets and other things in the system.

[whitelynx]

I've been looking at the different address families available in HawkNL, and it got me thinking that it might be useful to have two things: subclasses of Address for each address family, and a convenience function to create an instance of the correct Address subclass, given a valid address in string form. Basically it'd parse the address to determine what address family it is using, and create the appropriate Address object.

Also, if we combine the address family into the Address class and subclasses, then we may not need to manually specify the address family when creating a ConnectSocket from and Address. We'd still have to specify it for ListenSocket, but that's fine.

[whitelynx]

In HawkNL, (as far as I can tell) groups are basically ersatz sockets that can be written to and read from just like any standard socket that allow you to effectively do software multicasting. They're an interesting concept, and something definitely worth retaining for RaptorNL. The question is, however, how should we go about doing this? I'm not entirely sure how HawkNL went about implementing them, but they used file descriptors to represent groups, same as for sockets. Personally I think this could be done as a class instead, one which inherits from Socket. I'll have to take a closer look at HawkNL's implementation to be sure, but I think that'd be the way to go for this.

[whitelynx]

Ok, we've been doing some massive work on RaptorNL as of late. The next really big thing we'll be needing to do as far as design is concerned deals with how to handle what used to be HawkNL's 'driver' struct. Please take a look at https://kashmir.g33xnexus.com/projects/raptornl/wiki/Design/Refactoring and let us know if you have any thoughts.