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.