[Ns-developers] ns3 TCP merge candidate
raj.b at gatech.edu
Wed Jan 23 10:36:50 PST 2008
On Jan 23, 2008 11:39 AM, Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> hi raj,
> On Wed, 2008-01-23 at 08:26 -0500, Raj Bhattacharjea wrote:
> > 2. The Socket base class got a Listen() API that does nothing
> > (overridden in TcpSocket subclass).
> > 3. The Socket base class has a pure virtual GetType method that
> > returns an enum SocketType (SOCK_STREAM, SOCK_DGRAM, etc).
> > 4. The PacketSocket and UpdSocket implement the above pure virtual in
> > the correct way.
> > 5. The PacketSink app now checks for the presence of a SOCK_STREAM,
> > and appropriately calls Listen and Close.
> PacketSink should be able to perform these two operations
> unconditionally which would make it unnecessary to add 3) and 4).
The core of the issue is that different types of sockets have different
semantics i.e. stream sockets variously require Connect/Listen/Close while
datagram types don't. As I see it, there are two options
1. Our generic applications try and figure out what type of socket
they are using, and use the appropriate semantics.
2. Applications should assume they are working with the socket type
which is the logical superset of all others, and any unsupported specific
APIs will all be no-ops with error codes.
I believe you are advocating #2? I have no problem with this, but note that
if so, the on-off app needs to change to use stream semantics, and I think
that essentially all future applications that are supposed to work with
multiple transport layers will have to talk in terms of stream sockets
regardless of the actual socket type being used.
Georgia Institute of Technology
School of Electrical and Computer Engineering
More information about the Ns-developers