flasht
asked on
GNU C SSL AND KEEP-ALIVE
Any ideas why C is waiting for keep-alive timeout (disconnection of socet) when reading last buffer? I mean i got this code:
while(SSL_read(ssl,bufr,10
printf(bufr);
}
Simple... request is HTTP request with Keep-Alive set to 30 seconds.
But... what it does is:...
- prints first buffer (first 1024 bytes) with no visible delay
- prints second buffer (second 1024 bytes) with no visible delay
- prints third buffer (its not full 1024, its 768 bytes) after 30 seconds of delay (after disconnect from server side, cose keep-alive ended).
Any idea how to fix it, so it wouldn't wait for connection close? I would like to send another data on same connection(!)
With connection:close it works ok, shows reply in no-time.
Best regards,
FlashT
while(SSL_read(ssl,bufr,10
printf(bufr);
}
Simple... request is HTTP request with Keep-Alive set to 30 seconds.
But... what it does is:...
- prints first buffer (first 1024 bytes) with no visible delay
- prints second buffer (second 1024 bytes) with no visible delay
- prints third buffer (its not full 1024, its 768 bytes) after 30 seconds of delay (after disconnect from server side, cose keep-alive ended).
Any idea how to fix it, so it wouldn't wait for connection close? I would like to send another data on same connection(!)
With connection:close it works ok, shows reply in no-time.
Best regards,
FlashT
ASKER
What do you mean by "code running on reveiving side"? I'm kind of sure, that it waits after receiving all data because when I change it to Connection:Close, everything works just fine. I've wrote similar application in PHP, and it doesn't wait... in neither of cases.
>> What do you mean by "code running on reveiving side"?
The code that is running on the receiving side of the socket ... Presumably the code that prints the received buffers in your example.
Did you check with a network sniffer, or other means, whether the data was sent or not ?
The code that is running on the receiving side of the socket ... Presumably the code that prints the received buffers in your example.
Did you check with a network sniffer, or other means, whether the data was sent or not ?
ASKER
Isn't the code I gave a recieving side of the socket?
Any idea how do I sniff it on debian without x-window?
As far as I know SSL_read waits for "zero-byte", that isn't send from remote until disconnection...
Any idea how do I sniff it on debian without x-window?
As far as I know SSL_read waits for "zero-byte", that isn't send from remote until disconnection...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I abandoned the project, couldnt make it work
If the data makes it to the TCP send buffer, then it will generally be sent within a fraction of a second - a wait of 30 seconds before sending data could happen when there's network congestion or something similar, but not in the normal case.
So, either the sending application is holding on to the data, and hasn't passed it to the TCP send buffer yet. But that probably doesn't make sense, because the close operation on the socket has no information about the data, so it wouldn't send it either.
Or, the receiving application waits for blocks of 1024 bytes only, and does not read the data until 1024 bytes is available. This sounds more plausible.
You can easily check whether the data was actually sent or not by using a network sniffer (WireShark for example).
What code is running on the receiving side ?