Echoing back data from a packet sink

[Ubaid ur Rahman]

Hello,

I am new to ns3, and I was trying to implement a request and response architecture. I am trying to modify the PacketSink application to echo back the size of data requested by client. Socket use TCP. Sending data works, I am able to read the packet but when I echo it back with

socket->SendTo(packet, 0, from)

in HandleRead method it don't work. I displayed its result and it returns -1. I don't know how to dug deep to find the issue.

Can anyone show me the right direction?

Thanks in Advance...

[Konstantinos]

Hi Ubaid,

I do not know if it is a bug or a 'feature' (meaning normal expected behaviour) but you are using TCP sockets and the SendTo is the same as Send (if you see in the code)

684 /* Inherit from Socket class: In TcpSocketBase, it is same as Send() call */

685 int

686 TcpSocketBase::SendTo (Ptr<Packet> p, uint32_t flags, const Address &address)

687 {

688  return Send (p, flags); // SendTo() and Send() are the same

689 }

This means that you will try to send to the host that this socket was bind/connected (if I'm correct). 

Try to debug it and see exactly which error is fired. I would expect the 'not connected' especially if you are using the 'Address::Any' for the packetsink.

Which means that you might need to create a new outgoing socket or 'connect' to the remote host (from) before you send.

Regards,

K.

PS there are other experts in the list more familiar with TCP that might reply and correct me if I'm wrong.

[Ubaid ur Rahman]

Thank you for your reply.

I did some changes to my script after your reply:

1. I changed Address::Any() to a Ipv4 address
2. Try to use the Connect method again on socket inside HandleRead
3. Displayed the socket error no.

Issues:

1. Now the simulation stalls at HandleClose (when socket->Connect(from) is commented out).
2. Errorno is displayed 5 which is same as Socket's Enum ERROR_SHUTDOWN. I tried the debugging with gdb but nothing I guess I don't know how to use it right. I searched web for the reason why this error is fired no description on my search (may be I am not searching it right). Can this error be due to the methods "m_socket->ShutdownSend()" on PacketSink side and "m_socket->ShutdownRecv()" on the requesting node side.
   

[Tommaso Pecorella]

Hi,

no, the socket in HandleRead is already connected to the sender. There is no need to perform a new Connect and, most probably, it will fail since the other peer isn't accepting a connection.

The Send function should work, if it returns -1 the problem is elsewhere. I have a doubt (and it could, indeed, be a bug). Mind to post the sources so we can test them ?

Cheers,

T.

PS: the problem could be that the forked socket isn't setting the correct sender address when the original socket is bound to Any.

[Ubaid ur Rahman]

Hello,

Thank you for your reply!

I am attaching source files to this post, I am clearly puzzled! :(

[Tommaso Pecorella]

If you tell the socket to not send anything, it will not send anything...

tcp-responder.cc - line 117

 m_socket->ShutdownSend();

Comment it and it will work (well, at least it will echo back stuff). The line is good for PacketSink, because a Sink shouldn't send anything.

Have fun,

T.

[Ubaid ur Rahman]

Hello,

Works now sends the echo, thank you for your reply and your valued time. One more question though... If I want multiple requests to be handled by the TcpResponder, and I want it to return some data of different requested size along with THE REQUESTED DATA RATE can I do that? With multiple connection can I Schedule another packet's transmission so the data is transmitted to every requesting node/app with the App's settings for data rate (same as OnOffApplication). I simple words can the current connected socket in HandleRead be saved and passed to an event of Simulator::Schedule? (I don't know if I have explained my question well)

P.S If its a stupid question don't mind answering after all I am new to NS-3 :)

[Tommaso Pecorella]

Hi,

yes, it's a stupid question, but it's worth replying. Mind, it's stupid mostly because you didn't notice that you already have this feature...

If you check TcpResponder::HandleRead (Ptr<Socket> socket), each time a packet is received, the Rx socket is passed as an argument. Moreover, the received packet can be inspected to find out the Tx IP/port and the Rx IP/port. This should be more than enough to enable what you said.

Moreover, the socket passed to HandleRead is already stored in the m_socketList container (it's saved there during the connect). However, I wouldn't use the container if not to have a sanity check. You already have a pointer to the socket, you can pass that to another function though a direct call or a Scheduled event.

As I said, the question isn't stupid per-se. It is because you already have all you need, and you just didn't notice :)

Hope this helps,

T.

[Ubaid ur Rahman]

Hello,

Thank you so much for the insight... It did helped a lot. :) much appreciated