[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 387
  • Last Modified:

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,1024)){  
   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
0
flasht
Asked:
flasht
  • 3
  • 3
1 Solution
 
Infinity08Commented:
Are you sure the problem is not on the receiving end rather than the sending side ?

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 ?
0
 
flashtAuthor Commented:
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.
0
 
Infinity08Commented:
>> 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 ?
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
flashtAuthor Commented:
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...
0
 
Infinity08Commented:
>> Isn't the code I gave a recieving side of the socket?

You mean the SSL_read ? I missed that earlier.

The data is most likely stuck in the SSL layer (either on the sending or receiving side) or possibly in the stdout buffer, and not in the TCP/IP or lower layers.


>> As far as I know SSL_read waits for "zero-byte", that isn't send from remote until disconnection...

In the general case, it waits for a full record before processing it, because it needs to decrypt the data and perform integrity checks on it. As long as the record isn't completely received, it can't start processing it.


So, to summarize : two likely causes are :

(a) the full record hasn't been received yet, so SSL_read blocks until it receives the rest. Verify that with a network sniffer.

(b) the printf for showing the received data is buffered. An fflush(stdout) right after it should fix that kind of buffering problem.


>> Any idea how do I sniff it on debian without x-window?

tcpdump should do the trick.
0
 
flashtAuthor Commented:
I abandoned the project, couldnt make it work
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now