[Ns-developers] ns3 TCP merge candidate

[Raj Bhattacharjea]

On Jan 23, 2008 11:39 AM, Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
wrote:

> 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).
>
> ok.
>
> >    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.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Systems Analyst
404.894.2955