When you are worrking on managed socket application and your application is very extensively doing send/recieve on the socket, then probably you need to care about understanding the heap management. Socket.Recieve or Socket.Send finally need to call the underlying native winsock API call to recieve the data on user specified buffer. Same is true for NetworkStream.Read and NetworkStream.Write calls, because these methods also finally got translated socket send and recieve.
To make the native API call buffer need to pinned for I/O, these pinned buffer can not be moved when garbage collector is doing the work of cleaning up. If your application is using newly allocated buffer in slow network environment and application is doing multiple I/O call frequently then it is possible that you will hit the problem of heap fragmentation. If fragmentation is small, you probably do not need to worry about it, but if heap fragmentation is reaching more than 10% and you are seeing larger time spend on GC. You need to look into some better techniques to elliminate the unnecessary pressure on GC. One possible solution is create a pool of buffer in the startup and use object pooiling to reuse them as needed.
Check the maoni's blog entry Using GC Efficiently – Part 3 to understand more about pinning and effective usage of GC and other good tips.
This posting is provided "AS IS" with no warranties, and confers no rights