> Actually, the correct CIL signature for Stream.Read is:
> .method public hidebysig newslot virtual abstract
> instance int32 Read([in][out] unsigned int8[] buffer,
> int32 offset,
> int32 count) cil managed
More over the signature has interop attributes
[In] [Out].
Without these attribute the buffer isn't marshalled back in some situations (failed
sometimes).
I made some tests:
c#:
int read(byte[] buffer)
{
return 0;
}
ildasm:
.method private hidebysig instance int32 read(unsigned int8[] buffer) cil
managed
I added a interop Attribute In
int read( [In] byte[] buffer)
ildasm:
.method private hidebysig instance int32 read([in] unsigned int8[] buffer) cil
managed
I added a interop Attribute Out
int read( [In][Out] byte[] buffer)
.method private hidebysig instance int32 read([in][out] unsigned int8[] buffer) cil
managed
If I use the ref keyword
int read( ref byte[] buffer)
ildasm:
.method private hidebysig instance int32 read(unsigned int8[]& buffer) cil
managed
If I use the out keyword:
int read( out byte[] buffer)
the result from ildasm is:
.method private hidebysig instance int32 read([out] unsigned int8[]& buffer)
cil managed
The surprise is, that .net marshalling uses the [In][Out] interop attributes for
marshalling between .net components.
>
>
> The corresponding C# syntax for this is :
>
> public abstract int Read(ref byte[] buffer, int offset, int count);
see my remarks: the ref means I can allocate a new buffer inside the Read methode and
assign it to buffer.
But if the Methode is declared as
Read([In][Out] byte[] ...)
I can do it,but it wouldn't do the desired. The original buffer from the caller is
unchanged.
>
> in is not a valid parameter modifier in C#; so, I guess, this
> qualifies as a documentation error.
>
> Anyway, the out modifier causes the buffer to be transferred
> back. To avoid this, you can provide a wrapper for the Read
> method on your server component.
I don't want to avoid the transfert back, I want to avoid the transfer to the server.
>
> HTH,
>
> Stefan
> ----- Original Message -----
> From: Dirk Reuss
> To: [EMAIL PROTECTED]
> Sent: Wednesday, August 14, 2002 1:05 PM
> Subject: Why has a MarshallByRefObject Stream.Read(..)
> byte[] as IN Parameter
>
>
> Hello,
> I implemented a Stream for transfering data over the network.
> On the remote (client) side I have a proxy to a stream object.
>
> Client Code:
> Stream stream = remoteserverobject.GetStream();
> byte [] buffer = new byte[1024*1024];
> stream.Read(buffer,0,1024*1024) ;
>
> The buffer is transferd (1MB) from the client to the server
> and if the Read
> call returns the buffer is transfered back (OK). So the
> network volumn is
> 2MB.IMO that's 1MB to much.
>
> The signature for Read is:
>
> [C#]
> [Serializable]
> public abstract int Read(
> in byte[] buffer,
> int offset,
> int count
> );
>
> The buffer parameter is explicitly marked as in. I couldn't
> understand why.
> I think this happens not only for my channel.
> Is there any workaround with remoting attributes?
> Interop Marshalling Attributes don't work.
> The transport is Tcpip with TcpIpChannel.
>
> I tried:
> byte [] buffer = new byte[0];
> stream.Read(buffer,0,1024*1024) ;
>
> Stream::Read(byte[] buffer...)
> {
>
> }
>
>
> Regards,
> Dirk
>
> You can read messages from the Advanced DOTNET archive,
> unsubscribe from Advanced DOTNET, or
> subscribe to other DevelopMentor lists at
> http://discuss.develop.com.
>
>
> You can read messages from the Advanced DOTNET archive,
> unsubscribe from Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
