String concatenation optimized for avg. incoming packet size
Hi,
I'm currently working on a socket server that handles incoming ASCII encoded strings and I want to optimize the concatenation and framing of the incoming strings. Messages are stored in a buffer until message boundary is detected and released for processing.
So, what I'm basically wondering is, if it's of any benifit to use a StringBuilder for the concatenation of the incoming string or if I can simply concatenate strings with str += "incomingstring";
My thinking is that StringBuilder doesn't add much benefit because PPPoE MTU is at 1492 and my messages have varying lengths from 100 to 400 bytes, which "SHOULD" mean that I ususally get the whole message per incoming packet. Am I right with this assumption?
Any opinions welcome...
Thanks,
Tom
[822 byte] By [
TomFrey] at [2007-12-25]
It is recommended in by Microsoft to use StringBuilder when a huge number of Concatination is to be done, concatinating small number of strings in a span of time can be concatinated with + sign. Now you better know what your system is doing and how many concatination its need for a given span of time.
For details please have a look at this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt05.asp
Section: "String Operations"
Best Regards,
I'm aware of the differences between StringBuilder and String.
The question here is whether I'm correct that even when the server has a huge load with several thousand connected clients I can expect packets to arrive close to MTU size so I usually receive packets in one frame and thus I don't need to do a lot of concatenation or if under load scenarios can arise where I might receive only a few bytes per frame and thus need to do a lot of concatenation.
If I knew how the underlying winsock behaves under big load with clients connected via different routes with possible alteration of packet framing I wouldn't ask ...
Again, I'm not interested in the benefits of StringBuilder vs String but if winsock handles packet framing differently under load or if frames usually, no matter how big the load come in close to MTU size or total packet if message is a lot smaller than MTU.
Tom, you should not code an application based on OS TCP/IP send/receive size details. Those details may very well change between OS releases and are subject to a myriad of variables. As you know a TCP socket provides a data stream and it is an requirement of the application to frame their data as needed. To ensure accuracy you should continue to apply your framing at the application layer. If you want message boundaries then you should look at UDP, but then you must note the reliability and delivery gaurantee differences between TCP and UDP
