Please can you help a hardware engineer, who almost understands what he's doing.
I'm using sTunnel 4.21 on a Windows 2000 machine, to provide a TCP program with SSL. This works very well.
However the application is very time critical and must finish sending block of XML as quickly as possible. I suspect there is a delay in either sTunnel or openSSL, while it waits to see if there are any more characters before sending a packet. Is this correct? If it is, is there a work round.
On Tue, 2008-03-04 04:21:28 -0800, Colin E wrote:
[..]
However the application is very time critical and must finish sending block of XML as quickly as possible. I suspect there is a delay in either sTunnel or openSSL, while it waits to see if there are any more characters before sending a packet. Is this correct?
Did you already set the TCP_NODELAY socket option?
HTH,
Ludolf
Ludolf Holzheid wrote:
However the application is very time critical and must finish sending block of XML as quickly as possible.
Did you already set the TCP_NODELAY socket option?
Thanks Ludolf.
Yes that is in the config, but I was wondering how long NODELAY is. In my application, what's important is to send a block of XML on a connection that's held open. Once the data has been sent, the timing isn't critical. However until the end of data is put in an SSL packet and sent, every 10mS is important.
I might be worrying about nothing, but I can't find it documented.
Colin
On Tue, 2008-03-04 08:02:16 -0800, Colin E wrote:
Ludolf Holzheid wrote:
However the application is very time critical and must finish sending block of XML as quickly as possible.
Did you already set the TCP_NODELAY socket option?
Thanks Ludolf.
Yes that is in the config, but I was wondering how long NODELAY is.
Enabling TCP_NODELAY should disable the Nagle algorithm completely, not just shorten the send delay.
If TCP_NODELAY is enabled for stunnel is already, are you sure, your application doesn't use Nagle?
I might be worrying about nothing, but I can't find it documented.
Are you actually having a timing problem, or are you merely afraid of one? In doubt, you might check the timing with e.g. wireshark.
Ludolf
Ludolf Holzheid wrote:
Are you actually having a timing problem, or are you merely afraid of one? In doubt, you might check the timing with e.g. wireshark
I hadn't thought of that. I'll set it up on the testbed system. It is definitely slower than expected, but looking at the router log, there do seem to be unexplained peaks of activity, far larger than the amount of data I thought I was exchanging.
Thanks for your advice.
Colin
-
Colin E -
Ludolf Holzheid