[Csync2] "Can't set TCP_NODELAY on TCP socket."
Lars Ellenberg
lars.ellenberg at linbit.com
Mon Sep 5 18:47:38 CEST 2011
On Mon, Sep 05, 2011 at 08:38:37PM +0530, Samba wrote:
> Hi,
>
> Incidentaly, I'm also facing this problem suddenly all of a sudden on my dev
> system where csycn2 used to work flawlessly. I tried the ttcp.c (tcp test
> suite) with -D option (disable batch sending) and it worked fine. So, I'm
> surprised why csycn2 is compplaining about not able to set the TCP_NODELAY
> option.
It always complained about this, but it ignores this for incoming
connections in server mode. At least that's how I read the code.
For outgoing connections (client mode), this would be in fact an error.
But for incoming connections, or connections handed down from inetd,
this is tried, but ignored: the file descriptor in question may be just
a local unix socket or even pipe in that case, so socket options for tcp
would be expected to fail.
> Further, after reading the documentation about this particular TCP option
> i'm wondering why csycn2 is setting this option in the first place;
It is necessary, and required, because of the line-based design of the
csync2 network protocol.
> this option is said to increase the network traffic and wasted bandwidth,
> and that the speed increase because of setting this option would not be
> worth compared to the waste of bandwidth.
It will not have much effect on the bulk traffic caused by the actual
librsync based update, if one takes place.
> So, can we configure csync2 to not to set this option because we are using
No, I don't think so.
> csync2 to synchronize files across WAN and hence bandwidth is much costlier
> for us and we do not need the utmost speed either. Having said that, it will
> be really good to know the solution to overcome this issue "Can't set
> TCP_NODELAY on TCP socket".
You will have to dig deeper, and either convince me that this is in fact
the cause of your problems, or find out that maybe this is the last
message that is logged by csync2, but NOT the reason why the connection
is not established.
Cheers,
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
More information about the Csync2
mailing list