[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Determine size of remote object

René Titulaer

10/26/2004 9:15:00 AM

Dear all,

our application runs on a lap-top, users are connecting to a server using
gsm (9600 baud). We did choose for a windows application on the client and
now we have to choose how to get to the server: .net remoting or webservices.

Webservices will result in large messages, which we don't want but we can
compress them by using zip. On the other hand we can choose .net remoting
(tcp/binary). I like to compare webservices compressing with .net remoting. I
do already know the size when I use webservices/compressing (using soap
extensions).

Does anybody know how to determine the packet size of a remoting object?

Thanx,
René
3 Answers

Ken Kolda

10/26/2004 3:03:00 PM

0

I don't know of any built-in way to get the message size, but a couple of
ideas come to mind:

1) Use a tool such as TcpTrace to monitor the network activity between
client and server. It may be able to generate packet information such as
packet size.

2) Write your own "proxy" app which simply listens for data on a part and
forwards it to another server. The you can record whatever information you
want as the message goes through the wire.

3) Write a channel sink that records the size of each message as its being
serialized to the remoting stream.

Options #1 and #2 are probably the easiest to implement, especially if
you've never written a channel sink. Plus, they would give more accurate
results of what actually goes across the wire.

By the way, it is possible to use compression with remoting as well. There
are some third-party products such as GenuineChannels
(www.genuinechannels.com) that add this feature.

Ken


"René Titulaer" <RenTitulaer@discussions.microsoft.com> wrote in message
news:406CE987-0372-4EF4-9246-EA6EE4C2FDA1@microsoft.com...
> Dear all,
>
> our application runs on a lap-top, users are connecting to a server using
> gsm (9600 baud). We did choose for a windows application on the client and
> now we have to choose how to get to the server: .net remoting or
webservices.
>
> Webservices will result in large messages, which we don't want but we can
> compress them by using zip. On the other hand we can choose .net remoting
> (tcp/binary). I like to compare webservices compressing with .net
remoting. I
> do already know the size when I use webservices/compressing (using soap
> extensions).
>
> Does anybody know how to determine the packet size of a remoting object?
>
> Thanx,
> René


René Titulaer

10/27/2004 7:23:00 AM

0

Ken,

Thanks for your response. Does it make sense to encrypt binary data you
think? Do I gain anything when uisng compression on binary data?

Thanx!

"Ken Kolda" wrote:

> I don't know of any built-in way to get the message size, but a couple of
> ideas come to mind:
>
> 1) Use a tool such as TcpTrace to monitor the network activity between
> client and server. It may be able to generate packet information such as
> packet size.
>
> 2) Write your own "proxy" app which simply listens for data on a part and
> forwards it to another server. The you can record whatever information you
> want as the message goes through the wire.
>
> 3) Write a channel sink that records the size of each message as its being
> serialized to the remoting stream.
>
> Options #1 and #2 are probably the easiest to implement, especially if
> you've never written a channel sink. Plus, they would give more accurate
> results of what actually goes across the wire.
>
> By the way, it is possible to use compression with remoting as well. There
> are some third-party products such as GenuineChannels
> (www.genuinechannels.com) that add this feature.
>
> Ken
>
>
> "René Titulaer" <RenTitulaer@discussions.microsoft.com> wrote in message
> news:406CE987-0372-4EF4-9246-EA6EE4C2FDA1@microsoft.com...
> > Dear all,
> >
> > our application runs on a lap-top, users are connecting to a server using
> > gsm (9600 baud). We did choose for a windows application on the client and
> > now we have to choose how to get to the server: .net remoting or
> webservices.
> >
> > Webservices will result in large messages, which we don't want but we can
> > compress them by using zip. On the other hand we can choose .net remoting
> > (tcp/binary). I like to compare webservices compressing with .net
> remoting. I
> > do already know the size when I use webservices/compressing (using soap
> > extensions).
> >
> > Does anybody know how to determine the packet size of a remoting object?
> >
> > Thanx,
> > René
>
>
>

Ken Kolda

10/27/2004 2:55:00 PM

0

If the data crossing the wire needs to be secure, then encryption is a must,
even for binary data. As for compression, keep in mind that eve though the
data is binary, it's mostly text, so compression would still be highly
effective over a slow connection.

If you haven't done so already, check out the GenuineChannels product
(www.genuinechannels.com). It offers both compression and encryption built
in, both of which I've used. Even when using the binary formatter the
compression can reduce network traffic by 50% or more.

Ken


"René Titulaer" <RenTitulaer@discussions.microsoft.com> wrote in message
news:603A2337-2A62-49B9-BB52-C4AACBE2F121@microsoft.com...
> Ken,
>
> Thanks for your response. Does it make sense to encrypt binary data you
> think? Do I gain anything when uisng compression on binary data?
>
> Thanx!
>
> "Ken Kolda" wrote:
>
> > I don't know of any built-in way to get the message size, but a couple
of
> > ideas come to mind:
> >
> > 1) Use a tool such as TcpTrace to monitor the network activity between
> > client and server. It may be able to generate packet information such as
> > packet size.
> >
> > 2) Write your own "proxy" app which simply listens for data on a part
and
> > forwards it to another server. The you can record whatever information
you
> > want as the message goes through the wire.
> >
> > 3) Write a channel sink that records the size of each message as its
being
> > serialized to the remoting stream.
> >
> > Options #1 and #2 are probably the easiest to implement, especially if
> > you've never written a channel sink. Plus, they would give more accurate
> > results of what actually goes across the wire.
> >
> > By the way, it is possible to use compression with remoting as well.
There
> > are some third-party products such as GenuineChannels
> > (www.genuinechannels.com) that add this feature.
> >
> > Ken
> >
> >
> > "René Titulaer" <RenTitulaer@discussions.microsoft.com> wrote in message
> > news:406CE987-0372-4EF4-9246-EA6EE4C2FDA1@microsoft.com...
> > > Dear all,
> > >
> > > our application runs on a lap-top, users are connecting to a server
using
> > > gsm (9600 baud). We did choose for a windows application on the client
and
> > > now we have to choose how to get to the server: .net remoting or
> > webservices.
> > >
> > > Webservices will result in large messages, which we don't want but we
can
> > > compress them by using zip. On the other hand we can choose .net
remoting
> > > (tcp/binary). I like to compare webservices compressing with .net
> > remoting. I
> > > do already know the size when I use webservices/compressing (using
soap
> > > extensions).
> > >
> > > Does anybody know how to determine the packet size of a remoting
object?
> > >
> > > Thanx,
> > > René
> >
> >
> >