Actually from what I have seen the Receive is far more destructive
than the send in most systems (send tends to be very short lived while
receive generally lives alot longer).
As far as whether it makes a copy or not .. it appears to be pinning
the arrays (arraysegments) you hand to it. Here is some reflectored
code from the stack used with BeginSend(IList<ArraySegment>...)
internal void SetUnmanagedStructures(IList<ArraySegment<byte>> buffers)
{
int num1 = buffers.Count;
ArraySegment<byte>[] segmentArray1 = new ArraySegment<byte>[num1];
for (int num2 = 0; num2 < num1; num2++)
{
segmentArray1[num2] = buffers[num2];
}
this.m_WSABuffers = new WSABuffer[num1];
object[] objArray1 = new object[num1];
for (int num3 = 0; num3 < num1; num3++)
{
objArray1[num3] = segmentArray1[num3].Array;
}
base.SetUnmanagedStructures(objArray1);
for (int num4 = 0; num4 < num1; num4++)
{
this.m_WSABuffers[num4].Length = segmentArray1[num4].Count;
this.m_WSABuffers[num4].Pointer =
Marshal.UnsafeAddrOfPinnedArrayElement(segmentArray1[num4].Array,
segmentArray1[num4].Offset);
}
}
This certainly appears to be pinning my original arrays not making a
copy of them. I would have to go check for what it did with a byte []
as opposed to a IList<ArraySegment> but I would imagine it to be
similar
Cheers,
Greg
On 8/10/06, Peter Ritchie
<[EMAIL PROTECTED]> wrote:
Greg, I meant to chime in on this earlier... I'm currently waiting for
further clarification of documentation from Microsoft for WSASend[To]
(which is eventually used by Socket.BeginSend). What I've gotten from
Microsoft so far is that the memory given to WSASend, when asynchronous
(overlapped I/O), is copied (referred to as "capture" in the WSASend
documentation) before being returned from WSASend. As far as I can tell,
Socket.BeginSend also makes a copy of the memory it's asked to send, pins
it, then gives it to WSASend. If what I'm hearing from MS abount WSASend
and the "service provider's responsibility to capture [the buffer] ...
before returning from [the call to WSASend]" is true, it seems redundant
to copy these buffers and pin the copies if the buffer need only exist for
the duration of the WSASend call--unless they know something they're not
willing to tell. I was under the impression that memory assigned to a
reference can't move while it's being used in a method call, especially a
PInvoked call. Although it would be fairly trivial to test if the above
is false (but wouldn't be conclusive if not proven to be false), I haven't.
I don't know if your focus is mainly receive rather than send; but, I
thought the above might be of interest...
On Tue, 1 Aug 2006 17:15:47 -0400, gregory young <[EMAIL PROTECTED]>
wrote:
>Ok so I think everyone can agree that creating buffers on the fly in
>an async socket server is bad ... there is alot of literature
>available on the problems this will cause with the heap. I am looking
>at a few options to get around this.
>
>1) Have a BufferPool class that hands out ArraySegment<byte> portions
>of a larger array (large enough that it would be in the LOH). If all
>of the array is used create another big segment.
>
>2) Create a bunch of smaller arrays for use by the bufferpool class
>and have it hand them back
>
>In both 1 & 2 I would probably have the connection use their buffer
>for the duration of the connection. I would internally hold a list of
>the free blocks. When a connection was done ith its buffer it would
>have to release it back to this pool. My thought is that #2 might be
>better for dealing with cases where I want to shrink the number of
>buffers allocated from the previous maximum if needed.
>
>In general I lean towards #1 ... but figured I would check if I might
>be missing something.
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
--
If knowledge can create problems, it is not through ignorance that we
can solve them.
Isaac Asimov
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
