implement a request response connector via tcp socket
Antonello
I'm trying to develop a simple 2-nodes model to implement
a req-resp application via tcp socket. I've written all the code
for the apps to be installed, tcp client and tcp server, but I
got a couple of issues I still can't address:
- When I send packets over the channel, the TCP segsize
is always 536, instead of 1460 as expected and even the
CW does not seem to change
- Data is exchanged in a very slow way between parts, maybe
due to this useless fragmentation.
What I do is:
CLIENT:
- create the TCP socket
- bind it to a local interface
- connect it the remote peer
- send a request
- install the handler for the response
SERVER
- create the TCP socket
- bind it to a local interface
- listening on that interface
- set up the handlers for request and accept
- on a new accepted request set up the handler for the incoming data
- on a new connection setup the handler to send data back
I tried to start with a working app but there is no example of
sofisticated data "receiver" other than a packet sink. Is there
any example or best practices to use tcp sockets like in the
udp-client-server example ? I think you are not interested in
my code (if I'm wrong tell me :-)), I'm just looking for as many
"hello world" as possible !
many thanks,
Antonello
Tom Henderson
> Hi all,
>
> I'm trying to develop a simple 2-nodes model to implement
> a req-resp application via tcp socket. I've written all the code
> for the apps to be installed, tcp client and tcp server, but I
> got a couple of issues I still can't address:
>
> - When I send packets over the channel, the TCP segsize
> is always 536, instead of 1460 as expected and even the
> CW does not seem to change
TCP does not try to do path MTU discovery. The 536 is a conservative
estimate based on the minimum MTU that IPv4 routers are required to
handle (576 bytes), and ns-3's IPv4 stack does not do fragmentation:
.AddAttribute ("SegmentSize",
"TCP maximum segment size in bytes (may be adjusted
based on MTU discovery)",
UintegerValue (536),
MakeUintegerAccessor (&TcpSocket::GetSegSize,
&TcpSocket::SetSegSize),
MakeUintegerChecker<uint32_t> ())
Howver, the cwnd should be changing as expected (this has been tested in
some of the test programs).
>
> - Data is exchanged in a very slow way between parts, maybe
> due to this useless fragmentation.
>
> What I do is:
>
> CLIENT:
> - create the TCP socket
> - bind it to a local interface
> - connect it the remote peer
> - send a request
> - install the handler for the response
>
> SERVER
> - create the TCP socket
> - bind it to a local interface
> - listening on that interface
> - set up the handlers for request and accept
> - on a new accepted request set up the handler for the incoming data
> - on a new connection setup the handler to send data back
>
> I tried to start with a working app but there is no example of
> sofisticated data "receiver" other than a packet sink. Is there
> any example or best practices to use tcp sockets like in the
> udp-client-server example ? I think you are not interested in
> my code (if I'm wrong tell me :-)), I'm just looking for as many
> "hello world" as possible !
>
We're still looking for an equivalent to the UDP Echo program that we
have, for TCP; see
http://www.nsnam.org/bugzilla/show_bug.cgi?id=454
(contributions of such an example would be welcome).
- Tom
Antonello Paoletti
stuck on the req-resp model over TCP.
To implement a blocking receive is it correct to put a
while (socket->GetRxAvailable() <= 0);
before the recv ? I'm not sure of this, but it seems that
the recv() callback is called everytime a new packet (536 B) is available
to be fetched. For 1000 packets, 1000 calls.
I'm insane, right ? I'm trying to develop a simple way to implement
the posix blocking synchronous recv() so that a client
can block itself waiting for the response, after the request.
It seems to me that the system provides fragmentation but no
reassembling and I have to wait for every packet to be receveid
to perform the reassembling myself. The problem is that I don't
know how many bytes to wait for on client side.. Is there a way
(other than the close callback) to know that the transmission has
finished ? Lots of questions I know.. I'm new to NS3, thanks for
all the help ! Hope to achieve something useful for the community
(as well as for my thesis...)
A.
2010/10/23 Tom Henderson <to...@tomh.org>:
> --
> You received this message because you are subscribed to the Google Groups
> "ns-3-users" group.
> To post to this group, send email to ns-3-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ns-3-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ns-3-users?hl=en.
>
>