It would be helpful to include a test case that exposes the bug.  I went ahead
and modified tcp-large-transfer.cc to try and understand what the problem is.

The bottom line is that I don't understand this bug report.

You say TcpSocket::Connect(InetSocketAddress("127.0.0.1", n)) returns 0 in a
real-world application if no server exists.  My first comment is that there is
no such thing as a real-world application of TcpSocket::Connect().  Of course,
tcp-socket.h is completely undocumented, so any fingers I'm pointing are really
at developers.

I'm afraid I cannot parse, "Here i tracked Ns3 code, found it was due to
Ipv4StaticRouting::LookupStatic() returning hostRoute, it was true for UDP(no
connect) but not for TCP."

Here's how I think Connect() works:

UdpSocket::Connect() calls NotifyConnectionSucceded and returns 0 always, which
is why I can't understand your comment, "it was true for UDP."  

What TcpSocket::Connect() does is to check for a route to the destination using
ipv4->GetIfIndexForDestionation() and then if it finds one, it asynchronously
sends a SYN.  Thus, the only way you can get an error back from
TcpSocket::Connect is if the route to the host doesn't exist.  Since there's
really no synchronous connect happening, there's no way to determine if the
server exists at this point.

So UdpSocket::Connect() always succeeds, and TcpSocket::Connect succeeds if
there's a route to the host.

My take is that the system is operating as designed -- I think this is another
instance of the "ns-3 sockets doesn't work like BSD sockets issue" which seems
to be captured in bug 131 and the synchronous socket and socket helper work.  

I'm going to mark this a duplicate of bug 131.









*** This bug has been marked as a duplicate of bug 131 ***

(In reply to comment #1)

> My take is that the system is operating as designed -- I think this is another
> instance of the "ns-3 sockets doesn't work like BSD sockets issue" which seems
> to be captured in bug 131 and the synchronous socket and socket helper work.  

Are you saying that, in the real world, connect will synchronously wait for the
syn ack ? 

> Are you saying that, in the real world, connect will synchronously wait 
> for the syn ack ? 

I'm responding to the bug report by saying that ns-3 just calls down into TCP
to send a SYN and returns in TcpSocket::Connect().  Really I'm mostly saying
that there is no "real world" example of an ns3::TcpSocket::Connect() to refer
to.

But to answer your question, if this were BSD sockets, yes, I would expect a
connect() request on a TCP socket to block until some kind of positive or
negative response came back from the network or the server in question.  If the
response was a SYN ACK from the server it would ACK the SYN ACK and then put
the socket into established and wake the connect() returning to the client.

This is how I remember it working back in the year 1725 anyway :-)

(In reply to comment #3)

> But to answer your question, if this were BSD sockets, yes, I would expect a
> connect() request on a TCP socket to block until some kind of positive or
> negative response came back from the network or the server in question.  If the
> response was a SYN ACK from the server it would ACK the SYN ACK and then put
> the socket into established and wake the connect() returning to the client.
> 
> This is how I remember it working back in the year 1725 anyway :-)

I did look the linux tcp code and did not find anything which would make
connect block in this case. i.e., the relevant code I found:
net/ipv4/tcp_output.c:tcp_connect

This is not a big deal but I was curious.