Re: Force packetise and interesting phenomena with two listening sockets
Re: Force packetise and interesting phenomena with two listening sockets
- Subject: Re: Force packetise and interesting phenomena with two listening sockets
- From: Ladd Van Tol <email@hidden>
- Date: Thu, 16 Oct 2008 09:11:32 -0700
If you're concerned about latency, you can turn off the Nagle
algorithm -- this is usually only recommended for interactive
applications that can sacrifice some throughput for an reduction in
latency. This will increase the number of packets you send, although
it will probably not result in a 1:1 correspondence between writes and
packets.
Setting this up would look something like this:
int flag = 1;
int result = setsockopt(sock, /* socket affected */
IPPROTO_TCP, /* set option at
TCP level */
TCP_NODELAY, /* name of option */
(char *) &flag, /* the cast is
historical
cruft */
sizeof(int)); /* length of option
value */
(copied from Google -- not tested)
- Ladd
On Oct 15, 2008, at 4:27 PM, Liwei wrote:
[Sorry if I missed something obvious, coding way past my sleeping
hours]
I wonder how I can force my data to be sent with as a single packet
under TCP with each call to either send() or CFWriteStreamWrite()
instead of bunching them up into multiple big packets. It seems to be
able to do that under UDP but not TCP.
Rephrase in case I'm not making sense:
How can I make sure that send() and CFWriteStreamWrite() sends one
packet per call?
The other problem is that I have two listening TCP sockets, one that
is purely for sending data, the other for receiving data. The
interesting thing is that when the sending side accepts a connection
before the receiving side, everything works properly, however if the
receiving side is connected first, select() on write returns with the
fd_set for write set to false and causes my application to not send
anything. I don't have the energy to test if the socket is really
blocked at the moment, but I believe what select() says.
Background on how the sockets are done, arguments in brackets are just
the interesting stuff, general idea, meaning I didn't actually try to
set the constant kCFSocketAutomaticallyReenableAcceptCallBack to
false:
CFSocketCreate() -> bind(INADDR_ANY) -> listen(1) ->
kCFSocketAutomaticallyReenableAcceptCallBack=false ->
kCFSocketAcceptCallBack -> CFSocketCreateWithNative(accepted_socket)
Both connections to the application are from two separate computers,
e.g. Computer1 connects to the write socket, Computer2 connects to the
read socket. I've also done both connections from each computer and on
the loopback interface as well, same results.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden