> What could be done to avoid the overhead is to have a method on the
> server that creates the byte array server side, then sends it back
> across to the client.
>
> byte[] Read(int offset, int count, int bufferSize, out int bytesRead)
> {
> byte[] buffer = new byte[bufferSize];
>
> bytesRead = myStream.Read(buffer, offset, count);
>
> return buffer;
> }
that would help, but then I couldn't use the stream in any stream context (e.g.
BufferedStream), because I added a Methode not known by other Stream consumers. I had
to wrap the Stream Proxy in a new Stream class and forward all calls to the proxy,
except the Read, which I had to rewrite like suggested above.
this would look like:
WrapperStream ws= new WrapperStream(remoteserver.GetStream());
ws->Read(buffer,0,1024*1024)
and would ony work for exactly my stream because the new
methode
byte[] Read(int offset, int count, int bufferSize, out int bytesRead)
is not in the Stream class.
Dirk
>
> James
>
> > -----Original Message-----
> > From: Moderated discussion of advanced .NET topics.
> > [mailto:[EMAIL PROTECTED]] On Behalf Of
> > Axel Heitland
> > Sent: Thursday, August 15, 2002 12:24 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [ADVANCED-DOTNET] Why has a MarshallByRefObject
> > Stream.Read(..) byte[] as IN Parameter
> >
> >
> > Hmm...
> >
> > What he has is a Stream at the server....
> >
> > So a read should surely transfer back the results to the
> > client (the [out] direction).
> >
> > The error is that the client unnecessarily uploads the bytes
> > to the server. This behaviour is time- and bandwidth consuming.
> >
> > Since Stream extends MarshalByRefObject it looks like the
> > Stream methods are not optimal modelled for remoting...
> >
> > If true that is a little bit more than just a documentation
> error ;-))
> >
> > My regards
> > Axel
> >
> > -----Original Message-----
> > From: Stefan Holdermans [mailto:[EMAIL PROTECTED]]
> > Sent: Donnerstag, 15. August 2002 14:52
> > To: [EMAIL PROTECTED]
> > Subject: Re: [ADVANCED-DOTNET] Why has a MarshallByRefObject
> > Stream.Read(..) byte[] as IN Parameter
> >
> >
> > Dirk,
> >
> > 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
> > {
> > }
> >
> > The corresponding C# syntax for this is :
> >
> > public abstract int Read(ref byte[] buffer, int offset, int count);
> >
> > 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.
> >
> > 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.
>
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.
