G33X Nexus Entertainment > RaptorNL

Idea: Socket class

(1/1)

whitelynx:
Right now we're making a thin class to wrap socket functionality, called Socket. I have some ideas for making it a bit more than a strict thin wrapper that I think might make it easier to use.


* Socket subclasses - create two smaller subclasses of Socket, ListenSocket and ConnectSocket, to handle the functionality for incoming and outgoing sockets, respectively. (if you're wondering about the names, take a look at any classic BSD sockets implementation) This makes all of the individual Socket files a bit easier to read through, as the read/write functionality is common to all sockets, but a listening socket can't connect, and a connecting socket can't listen.
* Move some functionality to the constructor - open() should only need to be called once during the lifetime of a socket, and it must be called before anything else can be done, so I think it makes sense to put that into the constructor. Similarly, either listen() or connect() must be called on a socket before anything except open(), so it would make sense to put those in the constructors of their respective socket types. (or, if we don't split Socket into subclasses, simply have convenience constructors that take care of the listen/connect functionality.)
* Move statistics functionality out of Socket - Statistics are nice, but I don't think their functionality logically belongs inside Socket... it may make more sense to move it to its own Statistics class that all Sockets register with, and they don't record statistics unless there is an attached Statistics object. (see my comments on the wiki for more thoughts)

Morgul:
As someone who knows 2% about sockets, I think this makes a good deal of sense. Even though I'm not in charge of this, I support the change. It would make a good deal more sense to deal with, imho.

I also really like the idea of moving statistics out of sockets. They don't belong there.

Rosencrantz:
Sounds good to me. Toss bind and listen into the constructor for ListenSocket, and connect into the constructor for ConnectSocket. I don't really know anything about the statistics, but your idea sounds good to me.

contingencyplan:
Well, I said I would have some comments for you when you woke up. Then I got involved in this Cooke paper, and all of a sudden it's almost 6am and I have a test in 5 hours. So my comments are gonna be brief for now.


--- Quote from: whitelynx on October 05, 2006, 06:18:34 pm ---
* Socket subclasses - create two smaller subclasses of Socket, ListenSocket and ConnectSocket, to handle the functionality for incoming and outgoing sockets, respectively. (if you're wondering about the names, take a look at any classic BSD sockets implementation) This makes all of the individual Socket files a bit easier to read through, as the read/write functionality is common to all sockets, but a listening socket can't connect, and a connecting socket can't listen.
--- End quote ---

Generally, I like the idea. We can move forward on this for now, and see where it takes us, reserving the right to backtrack sometime down the line.


--- Quote ---
* Move some functionality to the constructor - open() should only need to be called once during the lifetime of a socket, and it must be called before anything else can be done, so I think it makes sense to put that into the constructor. Similarly, either listen() or connect() must be called on a socket before anything except open(), so it would make sense to put those in the constructors of their respective socket types. (or, if we don't split Socket into subclasses, simply have convenience constructors that take care of the listen/connect functionality.)
--- End quote ---

Again, generally like the idea. Again, we'll start moving on this path, and see what happens. I'll definitely know more when I start back in on the code later this week (after things have died down a bit school-wise).


--- Quote ---
* Move statistics functionality out of Socket - Statistics are nice, but I don't think their functionality logically belongs inside Socket... it may make more sense to move it to its own Statistics class that all Sockets register with, and they don't record statistics unless there is an attached Statistics object. (see my comments on the wiki for more thoughts)
--- End quote ---

Personally, I'd just as soon keep the stats within the Socket class. I don't see a reason for moving them to another class that the Socket then has to register itself with. As far as the performance gain (no stats are recorded unless the Socket is registered with the a Stats object), we can implement that a bit more simply as a flag (and perhaps using some magic make it perform just as well; dunno yet). To me, though, the stats are something that the Socket knows about itself, so it makes sense to have it within the Socket class. This is something I'd like to hear a more detailed argument for.

At any rate, I'm gonna call it a night. Cy'all tomorrow!

whitelynx:
For now, I'm not too worried about the statistics stuff... I think it clutters up the interface, but I can see why it's in Socket. Other than that, since there seems to be no argument about the other two points, I'm going to start implementing them.

Navigation

[0] Message Index