Large messages over TCP

Nov 9, 2012 at 12:23 PM

TCP protocol doesn´t guarantee that one write on the client will result in one receive on the server.. I´m sending large message (400Kb) over a TCP socket and this is resulting in more than one receive cycle on the server.. but I want my Command to execute just when the entire message arrives at the server... how can I do that with SuperSocket API ?

Is there a buffering strategy to deliver the entire message to the command?

I looked at the API and didn´t figured it out how it works...

Coordinator
Nov 9, 2012 at 12:42 PM
Could you tell me your protocol (request format)?

Sent from my Windows Phone

From: rodrigoreis22
Sent: 11/9/2012 9:23 PM
To: kerry-jiang@hotmail.com
Subject: Large messages over TCP [SuperSocket:402552]

From: rodrigoreis22

TCP protocol doesn´t guarantee that one write on the client will result in one receive on the server.. I´m sending large message (400Kb) over a TCP socket and this is resulting in more than one receive cycle on the server.. but I want my Command to execute just when the entire message arrives at the server... how can I do that with SuperSocket API ?

Is there a buffering strategy to deliver the entire message to the command?

I looked at the API and didn´t figured it out how it works...

Nov 10, 2012 at 10:47 AM

My protocol request format is something like this:

[COMMAND NAME] [AUTH_TOKEN] [SIGN_CODE] [MESSAGE_BODY]

Sign code and message body are encrypted using RSA Asymetric Key. On the CommandReader I get the bytes after the AUTH_TOKEN and decrypt them using the private key.

Coordinator
Nov 10, 2012 at 12:35 PM

It doesn't seem enough, because the server doesn't know when one this kind request end.

I suggest you define the length of the MESSAGE_BODY in the message head or a end mark of the MESSAGE_BODY.

Probably, you should take a look this doc of SuperSocket 1.5:

http://supersocket.codeplex.com/wikipage?title=The%20Built-in%20Common%20Format%20Protocol%20Implementation%20Tools

Nov 10, 2012 at 12:52 PM

I could use terminator.. but the problem is that the message is encrypted and this is an application specific feature.. on the SuperSocket level I don´t have the private key to decrypt the message and thus, the terminator will never be reached.

Coordinator
Nov 10, 2012 at 12:57 PM
I suggest you to add a body length field in request head. Message head is plain data but message body can be encrypted.
From: [email removed]
Sent: Saturday, November 10, 2012 9:52 PM
To: [email removed]
Subject: Re: Large messages over TCP [SuperSocket:402552]

From: rodrigoreis22

I could use terminator.. but the problem is that the message is encrypted and this is an application specific feature.. on the SuperSocket level I don´t have the private key to decrypt the message and thus, the terminator will never be reached.

Nov 10, 2012 at 3:15 PM
kerryjiang wrote:
I suggest you to add a body length field in request head. Message head is plain data but message body can be encrypted.
From: [email removed]
Sent: Saturday, November 10, 2012 9:52 PM
To: [email removed]
Subject: Re: Large messages over TCP [SuperSocket:402552]

From: rodrigoreis22

I could use terminator.. but the problem is that the message is encrypted and this is an application specific feature.. on the SuperSocket level I don´t have the private key to decrypt the message and thus, the terminator will never be reached.

Ok. I´ll try this.

Nov 10, 2012 at 4:07 PM

Why do you allocate a buffer based on the MaxConnectionNumber and ReceiveBufferSize ? 

In my scenario I want a receive buffer size of 400000 bytes and MaxConnectionNumber > 15000 .. this way this server will consume a lot of memory.

Why not allocate the receive buffer dynamically when necessary??

Coordinator
Nov 11, 2012 at 12:43 AM
You shouldn't set so large receiving buffer size. Please keep it default at first!

Sent from my Windows Phone

From: rodrigoreis22
Sent: 11/11/2012 1:07 AM
To: kerry-jiang@hotmail.com
Subject: Re: Large messages over TCP [SuperSocket:402552]

From: rodrigoreis22

Why do you allocate a buffer based on the MaxConnectionNumber and ReceiveBufferSize ?

In my scenario I want a receive buffer size of 400000 bytes and MaxConnectionNumber > 15000 .. this way this server will consume a lot of memory.

Why not allocate the receive buffer dynamically when necessary??

Nov 12, 2012 at 11:04 AM

I understood that the receive buffer size is not a constraint.. it´s used as a temporary buffer for reading data from socket. But when server initializes you allocate a global buffer based on MaxConnectionNumber and ReceiveBufferSize and for each client you assign an offset on that buffer. Why not allocate the receive buffer just when a new client connects??

Coordinator
Nov 13, 2012 at 3:18 AM
Edited Nov 13, 2012 at 3:19 AM

It's a best practice of high performance socket programming. Pre-allocate receiving buffer can reduce GC collecting times.

http://archive.msdn.microsoft.com/nclsamples