Sockets and Buffer size

[Steven]

Hi,

I need to write an application using sockets.
I have a server and about 10 clients "speaking" at the same time with the
server, so i guess i need to use asynchronous sockets.
But the server will receive from the clients an ascii string with a
viariable length.
And in all the example i found, the size of the buffer is always fixed
(private byte[] theBuffer = new byte[1024]).
I probably misunderstood the use of the buffer !
I thought i could choose the largest size possible, and then decide that a
special char (# for example) will end the stream, but i'm not sure of this,
and don't know how to do this ?!

Thanks for any help !

 

[Nick Hounsome]

Hi,

I need to write an application using sockets.
I have a server and about 10 clients "speaking" at the same time with the
server, so i guess i need to use asynchronous sockets.
But the server will receive from the clients an ascii string with a
viariable length.
And in all the example i found, the size of the buffer is always fixed
(private byte[] theBuffer = new byte[1024]).
I probably misunderstood the use of the buffer !
I thought i could choose the largest size possible, and then decide that a
special char (# for example) will end the stream, but i'm not sure of
this, and don't know how to do this ?!

Thanks for any help !

The size of the buffer is always fixed because the full message must always
be assembled from parts. This is because the sender and the network can and
will chop the message into pieces - You might send it as 100 bytes but
receive it as 10,30 and 60 [This is an example only - in real life the
chunks are much bigger]. This is because TCP is a stream protocol not a
datagram protocol such as UDP (which wont work with huge messages for the
same reasons).

Because of the above it is almost always better to send the length first in
a fixed size format rather than use a terminator.

 

[PH]

Hi Steven;

You sould to use

Sockets.Bind(YourLocalEndPoint)
BeginRereive()
EndReceive()

EndReceive() returns the length of the packet.
Let's say your buffer is 2048 bytes, but the size of your packet is 230.
Then EndReceive() returns 230, now you might copy only the first 230
bytes from the buffer to a local array and process it for example.

I'm still learning this because I'm implementing it right now.
Good luck.


-----Original Message-----
From: Steven [mailto:[email protected]]
Posted At: Wednesday, March 08, 2006 8:02 AM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Sockets and Buffer size
Subject: Sockets and Buffer size

Hi,

I need to write an application using sockets.
I have a server and about 10 clients "speaking" at the same time with
the
server, so i guess i need to use asynchronous sockets.
But the server will receive from the clients an ascii string with a
viariable length.
And in all the example i found, the size of the buffer is always fixed
(private byte[] theBuffer = new byte[1024]).
I probably misunderstood the use of the buffer !
I thought i could choose the largest size possible, and then decide that
a
special char (# for example) will end the stream, but i'm not sure of
this,
and don't know how to do this ?!

Thanks for any help !

 

[PH]

Take a look at
http://msdn2.microsoft.com/en-us/library/attbb8f5(VS.80).aspx



If you are using a connectionless protocol such as UDP, you do not need
to listen for connections at all. Call the ReceiveFrom method to accept
any incoming datagrams. Use the SendTo method to send datagrams to a
remote host.





Good luck





-----Original Message-----
From: Steven [mailto:[email protected]]
Posted At: Wednesday, March 08, 2006 8:02 AM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Sockets and Buffer size
Subject: Sockets and Buffer size



Hi,



I need to write an application using sockets.

I have a server and about 10 clients "speaking" at the same time with
the

server, so i guess i need to use asynchronous sockets.

But the server will receive from the clients an ascii string with a

viariable length.

And in all the example i found, the size of the buffer is always fixed

(private byte[] theBuffer = new byte[1024]).

I probably misunderstood the use of the buffer !

I thought i could choose the largest size possible, and then decide that
a

special char (# for example) will end the stream, but i'm not sure of
this,

and don't know how to do this ?!



Thanks for any help !

 

[Jianwei Sun]

Hi,

I need to write an application using sockets.
I have a server and about 10 clients "speaking" at the same time with the
server, so i guess i need to use asynchronous sockets.
But the server will receive from the clients an ascii string with a
viariable length.
And in all the example i found, the size of the buffer is always fixed
(private byte[] theBuffer = new byte[1024]).
I probably misunderstood the use of the buffer !
I thought i could choose the largest size possible, and then decide that a
special char (# for example) will end the stream, but i'm not sure of this,
and don't know how to do this ?!

Thanks for any help !

You can read the message firstly and then assemble the message, for
example,

you have

private byte[] theBuffer = new byte[1024], if you don't find "#" in this
message, then you should put it in a temporary buffer, and append the
next read to it.

But you should know the maximum length of your message, if for
example,you made 10 reads, and with a message length of 10240 , and
still don't find the "#". And you know the maximum length of your
message is smaller than this, you should handle this as an "attacker"
situation and do some proper cleanup and termination of this.

Another way is to append the message length at the beginning of the
message, that way, you always know the size of message.

John.

 

[William Stacey [MVP]]

For 10 clients, I would not even use async but a thread per client server
design (sync server). Tons easier and perf would be the ~same as async. As
far as buffer size. If you using tcp, then send len prepended messages.
Then you can read the len and read the data bytes until you got N bytes.
Pretty easy and flexible and your messages can be almost any size so your
not picking some arbitrary number up front.

--
William Stacey [MVP]

| Hi,
|
| I need to write an application using sockets.
| I have a server and about 10 clients "speaking" at the same time with the
| server, so i guess i need to use asynchronous sockets.
| But the server will receive from the clients an ascii string with a
| viariable length.
| And in all the example i found, the size of the buffer is always fixed
| (private byte[] theBuffer = new byte[1024]).
| I probably misunderstood the use of the buffer !
| I thought i could choose the largest size possible, and then decide that a
| special char (# for example) will end the stream, but i'm not sure of
this,
| and don't know how to do this ?!
|
| Thanks for any help !
|
|
|
|
|

 

[Steven]

Thanks for your answer.

When you say "For 10 clients, I would not even use async but a thread per
client server design (sync server)", do you mean that async sockets should
be used when having a lot of simultaneous clients, and that for a low number
of clients it's "enough" to use threads which are easier to use ?

Thanks !

 

[William Stacey [MVP]]

That is a good way to put it Some have done server's with something
like 1700+- threads (i.e. clients) with good perf. I personally would not
go that high and may think about async at about 1000 concurrent connections.

--
William Stacey [MVP]

| Thanks for your answer.
|
| When you say "For 10 clients, I would not even use async but a thread per
| client server design (sync server)", do you mean that async sockets
should
| be used when having a lot of simultaneous clients, and that for a low
number
| of clients it's "enough" to use threads which are easier to use ?
|
| Thanks !
|
|

 

[Chris Mullins]

| When you say "For 10 clients, I would not even use async but a thread
per
| client server design (sync server)", do you mean that async sockets
| should be used when having a lot of simultaneous clients, and that
| for a low numberof clients it's "enough" to use threads which are
| easier to use ?

With 10 clients connected you could put together just about any
infrastructure you wanted for socket handling. Just for fun, you could
dynamically emit code into an assembly using the CodDom for each and every
incoming stanza, open a remoting channel to your new assembly, remote over
to it, start a COM+ Distributed Transaction, commit it, encrypt the results,
burnt them to CD, have a robotic arm move the CD between machines (gotta
archive this stuff, right?), commit the transaction, end the remoting call,
tear down the channel, and as long as you remembered to unload your emitted
assembly from your AppDomain everything would still work file. Even if you
forgot to unload your emitted assemblies it would still probably work for a
long time before running out of resources.

Modern hardware is so fast, and 10 connections so few, that you can get
ayway with pretty much anything.

Now, that said, I would still use Async sockets - I think they're the
easiest way to go and I know them quite well. Others may call me crazy.
Others may go further and call me names not printable here.

The real answer though is do it however you're most confortable.... and
whatever you do, don't make the rookie move and turn off Nagel's agorithm
thinking it'll help performance.

 

[William Stacey [MVP]]

You left out the part about using Egyptian Carrier Pigeons to move the CDs
between machines.

 

[Willy Denoyette [MVP]]

Let's see 1700 threads means 1.7GB of VM allocated for the thread stacks.
That means using .NET that there is not that much left for the application
once the CLR and the framework is loaded.
It's really a bad idea to create that number of threads in windows,
especially for sockets which can easily be bound to IOC ports that do not
use threads at all.

Willy.


| That is a good way to put it Some have done server's with something
| like 1700+- threads (i.e. clients) with good perf. I personally would not
| go that high and may think about async at about 1000 concurrent
connections.
|
| --
| William Stacey [MVP]
|
| || Thanks for your answer.
||
|| When you say "For 10 clients, I would not even use async but a thread per
|| client server design (sync server)", do you mean that async sockets
| should
|| be used when having a lot of simultaneous clients, and that for a low
| number
|| of clients it's "enough" to use threads which are easier to use ?
||
|| Thanks !
||
||
|
|

 

[William Stacey [MVP]]

| Let's see 1700 threads means 1.7GB of VM allocated for the thread stacks.
| That means using .NET that there is not that much left for the application
| once the CLR and the framework is loaded.
| It's really a bad idea to create that number of threads in windows,
| especially for sockets which can easily be bound to IOC ports that do not
| use threads at all.

? The IOCP callbacks use IOCP threads from IOCP thread pool (1000 threads).
So on a busy server using async, you can still block the IOCP thread pool
and you can still run out of memory for the read buffers because of "pinned"
buffers and heap fragmentation (better in 2.0). So if you have 500 IOCP
threads in callback, and each does another async operation before returning,
your at 1000 pretty fast. The Indy guy claims he did 1700+ no problems.
But I would not go that high. 10s to 100s is no problem for a threaded
server.