EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Receive buffer overwritten

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
#6928
Posted: 07/14/2008 16:59:48
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

SSL Server socket receive buffer is overwritten if current message is not retrieved via ReceiveBuf before next message arrives. We are not using an event to read the data. Messages are arriving quicker than our repeat loop can pull them from the buffer, resulting in missed messages. Any suggestions?
#6931
Posted: 07/14/2008 22:21:18
by Eugene Mayevski (EldoS Corp.)

What we need from you:

When you ask for technical support, please try to describe the situation in details. "It does not work" is not something we can work with. To assist you in solving your problem we need to get the following information from you:

* information about our product that you are talking about. Please specify the name of the product, it's version, platform or edition or code package (depending on the product);
* information about your environment. This includes the name and version of the operating system, the name and version of the development tool that our product is used with. If our product is used in conjunction with some other software, please specify the name and version of that software too;
* steps to reproduce the problem. This can include small test project, screenshots (please don't send unpacked BMP and DOC files with images) test data files etc.

Please remember that the more informative is your report, the faster we will be able to help you perform your task.



Sincerely yours
Eugene Mayevski
#6942
Posted: 07/15/2008 17:25:09
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

Well, nowhere did we say "it does not work." You must have replied with a stock response there.

OK, to be more specific, We think the following fragment of code in SBServerSockets.pas is faulty:

procedure TElSecureServerClientWinSocket.HandleData(Sender: TObject; Buffer: pointer; Size: longint);
begin
if Size <= FRecvMaxSize then
begin
Move(Buffer^, FRecvBuffer^, Size);
FRecvWritten := Size;
end

Our problem is that we seem to lose a socket message if the above is called twice in rapid succession. You have a local property FRecvBuffer that holds the incoming Buffer. It doesn't look like a circular buffer or something list-based. It's just a single buffer. So if HandleData (which is an event handler) is called twice in a row really fast, the 1st message will be overwritten by the second message. There seems to be no provision for "stacking" up of the messages. The 2nd message is sent within 15 ms of the 1st one.

Our symptom is that we lose the 1st message in this scenario. Our "fix" is to delay the sending of the second message by two seconds to give the "receiving" side time to pick it up. If we take the delay out, we lose the 1st message.

But regular windows sockets don't work this way. Messages don't overwrite one another.

So my question is: is this really what might be happening? Do you really just have this one non-circular buffer that gets overwritten with any new message?

Thanks,

Joe
#6944
Posted: 07/16/2008 07:22:44
by Eugene Mayevski (EldoS Corp.)

Indeed this is a stock answer for a typical request, which unfortunately contains no information that would help understand the problem.

The code that you quoted is probably outdated. In our file this method looks like

Quote

procedure TElSecureServerClientWinSocket.HandleData(Sender: TObject; Buffer: pointer; Size: longint);
begin
if Size <= FRecvMaxSize then
begin
Move(Buffer^, FRecvBuffer^, Size);
FRecvWritten := Size;
end
else
begin
Move(Buffer^, FRecvBuffer^, FRecvMaxSize);
FRecvWritten := FRecvMaxSize;
SetLength(FBuffer, Size - FRecvMaxSize);
Move(PByteArray(Buffer)[FRecvMaxSize], FBuffer[1], Size - FRecvMaxSize);
end;
FDataReceived := True;
if (Assigned(FOldEventHandler)) and (not FBlocking) then
FOldEventHandler(Sender, Self, seRead);
end;


So you need to update your version.


Sincerely yours
Eugene Mayevski
#6952
Posted: 07/16/2008 12:54:22
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

Eugene. I guess you did not notice that there was no procedure 'end;' in the "snippet" I quoted, which would be clue that I didn't post the entire procedure.

Notice in my post I said it was a "fragment of code." I had hoped you would understand this phrase to know that it wasn't the entire procedure. Why paste in code that isn't apparently relevant?

We actually DO have the latest version and it matches the full procedure you pasted in above.

The part of the code I posted is the part we think there might be a problem. Because it looks to us like the FRecvBuffer property can be overwritten.

The question is, is this what is happening? Or do you do something special with FRecvBuffer like put it into a queue or a list somewhere else?

Thank you
Joseph
#6953
Posted: 07/16/2008 13:09:57
by Eugene Mayevski (EldoS Corp.)

I can guess anything, but your posts don't let one understand the complete picture. Is there a reproducible test case or a small test project available for our developers to test?


Sincerely yours
Eugene Mayevski
#6956
Posted: 07/16/2008 14:24:49
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

A developer would in fact understand exactly what we are talking about. I was very specific about our symptoms and even pointed out the part of YOUR code that looks suspect.

Anyone who developed that code would know about 'circular buffers' or 'queues' and other structures commonly used in socket software. We were hoping that the lack of such structures in this part of your code would stand out (to a developer) as something obviously wrong or incomplete, and quickly fixable.

I realize as a non-developer, or at least as someone who didn't develop that part of the code, you might not have direct knowledge of this.

We will try to come up with a test project for you, but we are under other deadlines right now, and it may take some time.
#6957
Posted: 07/16/2008 14:40:14
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

As an postscript: all your help desk (or developers) need to do is simply send two messages to a server as fast as possible and just verify that both are handled.

Your help desk or developers may already have such a test application handy. If so, please let us know and save us all some time.

Thank you...
#6961
Posted: 07/17/2008 03:02:56
by Ken Ivanov (EldoS Corp.)

Really, the issue you reported may occur if all the received data is not completely retrieved from TElSecureServerSocket once it is decrypted. Please find attached an updated unit, it should fix the problem.


[ Download ]
#6995
Posted: 07/18/2008 13:30:40
by Frontier  (Standard support level)
Joined: 06/03/2008
Posts: 8

Innokentiy, THANK YOU! This indeed looks very promising. Your fix looks exactly like what is needed. We are testing it now, but it'll take us a few hours (for other reasons) before we have positive confirmation.

We'll report back by tomorrow one way or the other, but as of now, it looks very good!

Thanks again!

Joseph
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 2247 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!