.NET Remoting slow, why?

[Solitude]

Hi,

We have a tiered application and we are using remoting and the trasportation
method. This works fabulous as expected by just connecting to local host. But
when we go over to a remote server it goes from milliseconds to 4-5 seconds
to complete a simple request.

Is there anyway to improve our remoting, we are using a BinaryFormatProvider
to send it over in binary format. And we have compression enabled and
encryption working using GenuineChannels. Having our objects that are remoted
implement ISerializable won't improve that will it? Cause if it was
serialization slowness problem wouldn't all senarios experience this
slowness? Could it be GenuineChannels that is making this all slow?

Thanks

Any help would be appreciated to speed up our process.

[Spam Catcher]

=?Utf-8?B?U29saXR1ZGU=?= <Soli...@discussions.microsoft.com> wrote in
news:14B5877E-384A-4A8A...@microsoft.com:

> Hi,
>
> We have a tiered application and we are using remoting and the
> trasportation method. This works fabulous as expected by just
> connecting to local host. But when we go over to a remote server it
> goes from milliseconds to 4-5 seconds to complete a simple request.

Are you serializing a lot of data?

> Is there anyway to improve our remoting, we are using a
> BinaryFormatProvider to send it over in binary format. And we have
> compression enabled and encryption working using GenuineChannels.
> Having our objects that are remoted implement ISerializable won't
> improve that will it? Cause if it was serialization slowness problem
> wouldn't all senarios experience this slowness? Could it be
> GenuineChannels that is making this all slow?
>

I found if you don't serialize too much data, remoting is fast. However, if
you're sending a lot of objects back and forth it gets quite slow quickly.

[Solitude]

So we aren't sending too much data back and forth.

Would implementing ISerializable on our objects and doing our own
serialization speed this up like some have suggested elsewhere?

Cause when I log into my Verizon wireless internet it takes even longer, but
that internet is pretty fast. But someone was telling me doing ISerializable
wouldn't matter cause if that was the problem then all connections regardless
of the speed would be having the same slow problem. Is this true?

[Solitude]

Also forgot to mention I was hosting it on my own remote server and me and my
friend connected to it through our remoting speedy. Then on his server I was
connecting to it very slowly. We are in the same area.

[Robson Siqueira]

What protocol are you using as a transport channel?

--
Regards,
Robson Siqueira
Enterprise Architect
"Solitude" <Soli...@discussions.microsoft.com> wrote in message
news:940CEB1D-38B4-49AB...@microsoft.com...

[msgroup]

Hi, Solitude:

Do you care for performance? If you do, you may need to see our
SocketPro at www.udparts.com. Our SocketPro is written from batching,
asynchrony and parallel computation with excellent performance. No common
frameworks can match our SocketPro under all of cases for all types of
networks.

See the real sample applications written from our SocketPro at
http://www.wramp.net/casestudies1.html. See the site
http://www.udaparts.com/groups/viewtopic.php?t=39

Regards,

"Solitude" <Soli...@discussions.microsoft.com> wrote in message

news:14B5877E-384A-4A8A...@microsoft.com...

[Solitude]

We are using the gtcp protocol from genuine channels. And even when we go
back to regular remoting using the tcp channel it still is slow for us.

So I also have been tracing our program, one call that logs the user on
(sends username, password and gets back a session object, very small object)
takes longer than another call that retrieves more data.

If I want performance is remoting not the way to go?

Thanks

[Solitude]

Does SocketPro do remoting fast?

Thanks

[James Crosswell]

Solitude wrote:
> We are using the gtcp protocol from genuine channels. And even when we go
> back to regular remoting using the tcp channel it still is slow for us.
>
> So I also have been tracing our program, one call that logs the user on
> (sends username, password and gets back a session object, very small object)
> takes longer than another call that retrieves more data.
>
> If I want performance is remoting not the way to go?

You really have to work out where the slowdown is coming from. Is it
coming from the serialization process, the transfer over the network
(bandwidth issues), the round trip time (latency issues) or a
combination of all of the above.

What happens if you run the server on another machine on the same lan
segment (on a 100 MB or 1GB lan) for example? On a really really fast
network connection, is the app responsive? If it is, then that would
indicate that the overhead incurred from serialization etc. has nothing
to do with it and it's simply the network transfer which is taking so long.

If the later is the problem then you could:
a) Run a tracert to try to identify any infrastructure problems like
flakey routers etc. between you and the server
b) Run a sniffer like Etherial to get an idea of the exact size and
quantities of data that are being transfered between your client and the
server

Once you have an idea of the amounts of data you're transfering, you
could run a few quick calculations to get an idea of how long this
"should" be taking on the kind of connection that you have and compare
that with what you're actually seeing.

It might be the case that one of the routers is spending a long time
analyzing the data in the packets or it could be a million and one other
things. Try to eliminate as many variables as possible from the equation
during testing and reproduce the problem (i.e. the slowdown) in a
minimalist environment. If you can reproduce it in a "lab" environment
(i.e. on a simple fast 100MB LAN with only a couple of machines on it)
then it will be much easier to identify where the problem is coming from.

btw: If you don't have the problem on a simple LAN but you do between
your box and your buddy's server then you might try using http instead
of tcp. In theory this should be slower but routers might pay closer
attention to the later than the earlier... so the results might
surprise. In any event, you'll certainly have to do a bit more detective
work in order to find the root cause.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

[msgroup]

Hi, Solitude:

It is SIGNIFICANTLY faster and more scalabler than .NET remoting and
other common remoting frameworks under ALL OF CASES for ALL TYPES OF
NETWORKS and ALL TPES of APPLICATIONS. Note that I emphases the words with
upper case. You will NEVER find a case that .NET remoting is faster than our
SocketPro.

I urge you to download our SocketPro at www.udaparts.com. Quickly do
reseach, starting from attached five tutorials. Afterwards, write your own
samples and compare our SocketPro with .NET remoting. You will see the above
statement.

Regards,

"Solitude" <Soli...@discussions.microsoft.com> wrote in message

news:2D1925AF-A042-4C3B...@microsoft.com...

[James Crosswell]

msgroup wrote:
> Hi, Solitude:
>
> It is SIGNIFICANTLY faster and more scalabler than .NET remoting and
> other common remoting frameworks under ALL OF CASES for ALL TYPES OF
> NETWORKS and ALL TPES of APPLICATIONS. Note that I emphases the words with

Is it faster than RemObjects using something like their SuperTCP channel
and their BIN message format? Have you ever run any comparison of your
product against theirs? If so, do you have any test results of
benchmarks or anything?

[Goran Sliskovic]

Solitude wrote:
> We are using the gtcp protocol from genuine channels. And even when we go
> back to regular remoting using the tcp channel it still is slow for us.
>
> So I also have been tracing our program, one call that logs the user on
> (sends username, password and gets back a session object, very small object)
> takes longer than another call that retrieves more data.
>
> If I want performance is remoting not the way to go?

...

I would suggest capturing TCP/IP protocol data using packet capture
tool. Ethereal is free and powerfull.

Regards,
Goran

[msgroup]

Hi, James:

We have compared our SocketPro with common frameworks like DCOM, and
.NET remoting, but have never compared SocketPro with uncommon frameworks.
However, we believe our SocketPro can match any communication frameworks
written from TCP protocol.

We urge you to download our SocketPro at www.udaparts.com, study a few
turtorials, write your own test samples and compare it.

Our SocketPro is written from batching, asynchrony and parallel

compuation. Here are a few samples code you can see only in our SocketPro.

Batching means:

void GetAllCounts(int &nCount, int &nGlobalCount, int &nGlobalFastCount)

{

GetAttchedClientSocket()->BeginBatching();

QueryCountAsyn();

QueryGlobalCountAsyn();

QueryGlobalFastCountAsyn();

GetAttchedClientSocket()->Commit(true); //true -- ask server to send three
results back in one batch

GetAttchedClientSocket()->WaitAll();

nCount = m_QueryCountRtn;

nGlobalCount = m_QueryGlobalCountRtn;

nGlobalFastCount = m_QueryGlobalFastCountRtn;

}

Asynchrony means:

Our SocketPro uses 100% non-blocking socket communication for both
client and server.

Parallel:

Two communication channels work concurrently within one thread WITHOUT
worker threads.

SocketPro does not use worker threads for conccurncy. It uses 100%
non-blocking socket communication for conccurncy.

Regards,

"James Crosswell" <ja...@microforge.net> wrote in message
news:uCARrLLQ...@TK2MSFTNGP06.phx.gbl...

[James Crosswell]

msgroup wrote:
> Hi, James:
>
> We have compared our SocketPro with common frameworks like DCOM, and
> .NET remoting, but have never compared SocketPro with uncommon frameworks.
> However, we believe our SocketPro can match any communication frameworks
> written from TCP protocol.

Thanks, I'm not actually looking for alternatives. The framework I'm
using is fast and reliable. Best of luck though.

[Dan Reber]

How about Genuine Channels? Is GC fast and reliable?

Thanks

Dan

"James Crosswell" <ja...@microforge.net> wrote in message

news:eSzD02MQ...@TK2MSFTNGP03.phx.gbl...

[msgroup]

Hi, James:

Let me re-modify the statements in the previous messages:

It is SIGNIFICANTLY faster and more scalabler than ANY .NET remoting and

other common remoting frameworks under ALL OF CASES for ALL TYPES OF
NETWORKS and ALL TPES of APPLICATIONS. Note that I emphases the words with

upper case. You will NEVER find a case that ANY .NET remoting is faster than
our SocketPro.

I urge you to download our SocketPro at www.udaparts.com. Quickly do
reseach, starting from attached five tutorials. Afterwards, write your own

samples and compare our SocketPro with ANY .NET remoting. You will see the
above statement.

Note that I have added three ANYs in front of .NET remoting .

Regards,

"James Crosswell" <ja...@microforge.net> wrote in message

news:eSzD02MQ...@TK2MSFTNGP03.phx.gbl...

[James Crosswell]

msgroup wrote:
> Hi, James:
>
> Let me re-modify the statements in the previous messages:
>
> It is SIGNIFICANTLY faster and more scalabler than ANY .NET remoting and
> other common remoting frameworks under ALL OF CASES for ALL TYPES OF
> NETWORKS and ALL TPES of APPLICATIONS. Note that I emphases the words with
> upper case. You will NEVER find a case that ANY .NET remoting is faster than
> our SocketPro.

I thought we already went over that... I asked you if it was faster than
a specific framework and you said you had no idea and certainly no
benchmarks to confirm such. Are you saying you now know more?

[msgroup]

Hi, James:

I have a quick look at your metioned frameworks in previous messages. At
this time, I don't think that those frameworks can match our SocketPro in
performnace, scalability, features, robustness and security.

Why don't you download a copy of SocketPro at www.udaparts.com for your
experiments with five tutorials and others? You may post more questions at
http://www.udaparts.com/groups/viewforum.php?f=2&sid=023d7f7cbd4a5fbe47a717f9b6c84823.

Regards,

"James Crosswell" <ja...@microforge.net> wrote in message

news:O3v$II%23QHH...@TK2MSFTNGP05.phx.gbl...

[James Crosswell]

msgroup wrote:
> Hi, James:
>
> I have a quick look at your metioned frameworks in previous messages. At
> this time, I don't think that those frameworks can match our SocketPro in
> performnace, scalability, features, robustness and security.

Thanks for the benchmarks but, as I say, I have no need to change
frameworks since the one I'm using is great. I'd recommend RemObjects to
anyone and in conjunction with their DataAbstract it's the perfect tool
for transfering data between the middle tier and Windows or Web clients
and back again (as lean delta/change packets). DataAbstract is the
main reason I'm using it instead of .NET Remoting and the fact that I've
always experienced exceptional performance using the framework is just a
plus.

If you are REALLY serious about your products, you should at the very
least check out your competition - rather than telling people in here
that your product is way better than products you know nothing about...
you'd have a lot more credibility if you could produce benchmarks or, at
the very least, demonstrate a familiarity with the subject matter that
you're talking about (i.e. a comparison between your products and others
presently).

[msgroup]

Hi, James:

See my inline comments. Please don't hesitate to ask me any questions.

"James Crosswell" <ja...@microforge.net> wrote in message

news:ORmougHR...@TK2MSFTNGP03.phx.gbl...

> msgroup wrote:
>> Hi, James:
>>
>> I have a quick look at your metioned frameworks in previous messages.
>> At this time, I don't think that those frameworks can match our SocketPro
>> in performnace, scalability, features, robustness and security.
>
> Thanks for the benchmarks but, as I say, I have no need to change
> frameworks since the one I'm using is great. I'd recommend RemObjects to
> anyone and in conjunction with their DataAbstract it's the perfect tool
> for transfering data between the middle tier and Windows or Web clients
> and back again (as lean delta/change packets). DataAbstract is the main
> reason I'm using it instead of .NET Remoting and the fact that I've always
> experienced exceptional performance using the framework is just a plus.

I have just published messages to other people that SocketPro is able to do
many works and have many features that .NET remoting can't provide or is not
good to do. I have read through many other frameworks from different point
views. Some of them have very good implementation, but many of them are
poor.

Our SocketPro comes a free remote database service at
http://www.udaparts.com/document/articles/dialupdb.htm. You can use the
service to remotely access ANY data sources (MS SQL, Oracle, Access, DB2,
mySQL, ......) through MS OLEDB technology from a window desktop, a device
(pocket pc) and smartphone (soon)! In addition, I am sure that this service
is faster and more scalable than DataAbstract under all of cases for all of
platforms. Let me tell you reasons soon. Don't be angry with me! If you find
one case, I will be very glad to pay you $100.00. This is my offer to you.
Can you take this challendge?

>
> If you are REALLY serious about your products, you should at the very
> least check out your competition - rather than telling people in here that
> your product is way better than products you know nothing about... you'd
> have a lot more credibility if you could produce benchmarks or, at the
> very least, demonstrate a familiarity with the subject matter that you're
> talking about (i.e. a comparison between your products and others
> presently).

Actually, I had a quick glance to frameworks after you metioned, but I just
did not want to comment other software providers. Your message forces me to
lead me to talk about RemObjects. I would say that RemObjects lack a set of
key features from its good documentation. Here are a set of key problems for
RemObjects.

1. RemObjects has not nothing to protected user sensitive data from its
documentation. SocketPro provides two-builtin methods to protected sensitive
data, industrial standard SSL/TLS and UDAParts security protocol. You can
also write your own code to protect your sensitive code.

2. RemObjects don't provide real-time notification service, but SocketPro
provides bi-directional asynchronous real-time notification service as shown
in many attached samples and tututorials and at the site
http://www.udaparts.com/document/articles/chatservice.htm

3. RemObjects use blocking socket for communication, but SocketPro uses
100% non-blocking socket in transportation layer. Non-blocking socket is
much more powerful than blocking socket. Because of its special design, you
can see a lot of codes like below that you can't find anywhere else.

void GetAllCounts(int &nCount, int &nGlobalCount, int &nGlobalFastCount)

{

GetAttchedClientSocket()->BeginBatching();

QueryCountAsyn();

QueryGlobalCountAsyn();

QueryGlobalFastCountAsyn();

GetAttchedClientSocket()->Commit(true); //true -- ask server to send three
results back in one batch

GetAttchedClientSocket()->WaitAll();

nCount = m_QueryCountRtn;

nGlobalCount = m_QueryGlobalCountRtn;

nGlobalFastCount = m_QueryGlobalFastCountRtn;

}

I am not sure if you understand the above code. Please take a little
while to analyze the above "strange code", and try your best to understand
the influence of batching on application performance. Because of this
feature, I can conlude the below statement:

It is SIGNIFICANTLY faster and more scalabler than ANY .NET remoting and
other common remoting frameworks under ALL OF CASES for ALL TYPES OF
NETWORKS and ALL TPES of APPLICATIONS. Note that I emphases the words with
upper case. You will NEVER find a case that ANY .NET remoting is faster than
our SocketPro.

I would like you to write a sample to challendge our SocketPro. If you
find a case that RemObjects or other .NET remoting frameworks is faster or
more scalable than our SocketPro, I would like to pay you $100! Please take
this offer. Additionally, I am available at sup...@udaparts.com. If you are
serious, we could communicate with each other if you like.

If you like, I can continue to list others here.

Cheers!

[James Crosswell]

msgroup wrote:
> 1. RemObjects has not nothing to protected user sensitive data from its
> documentation. SocketPro provides two-builtin methods to protected sensitive
> data, industrial standard SSL/TLS and UDAParts security protocol. You can
> also write your own code to protect your sensitive code.

Actually RemObjects supports various encryption methods out of the box
(including SSL if you use their http channels) and allows you to support
your own encryption method if you want.

> 2. RemObjects don't provide real-time notification service, but SocketPro
> provides bi-directional asynchronous real-time notification service as shown

Using their SuperTCP channel gives you full bi-directional
communication. All calls over that channel are threaded and you can have
multiple threads using a single SuperTCP channel simultaneously. They
have various asynchronous channels as well.

> 3. RemObjects use blocking socket for communication, but SocketPro uses

Again, that completely depends on the channel that you chose to use when
using RemObjects. The HTTP channel is blocking yes - but they have Async
channels as well.

> I am not sure if you understand the above code. Please take a little
> while to analyze the above "strange code", and try your best to understand

Looks quite nice - quite like the asynchronous calling of Delegates and
the similar WaitAll() method when calling these asynchronously.

> It is SIGNIFICANTLY faster and more scalabler than ANY .NET remoting and

I'm still not convinced that you or anyone else could be certain of that
given that you don't actually have any tests or benchmarks to
objectively measure this. If you are going to go making wild statements
like that then back them up with some data.

> I would like you to write a sample to challendge our SocketPro.

Ah, now that would be your job! I'm not the one who made bold claims
about my remoting framework being the greatest thing since sliced
bread... Don't get me wrong, it might very well be but if you're going
to go round saying it is you've got to have some muscle behind your punch.

[msgroup]

Hi, James:

Glad to have such a talk. Please see my inline comments. Don't hesitate
to ask me qustions.

"James Crosswell" <ja...@microforge.net> wrote in message

news:eCa$TYKRHH...@TK2MSFTNGP06.phx.gbl...

> msgroup wrote:
>> 1. RemObjects has not nothing to protected user sensitive data from
>> its documentation. SocketPro provides two-builtin methods to protected
>> sensitive data, industrial standard SSL/TLS and UDAParts security
>> protocol. You can also write your own code to protect your sensitive
>> code.
>
> Actually RemObjects supports various encryption methods out of the box
> (including SSL if you use their http channels) and allows you to support
> your own encryption method if you want.

Because you say something for RemObjects, I downloaded this framework and
had a quick glance at its documentation. I really can't find any where to
metion SSL/TLS support in RemObjects. I may be wrong, but please let me know
where its documentation says SSL/TLS support?

>
>> 2. RemObjects don't provide real-time notification service, but
>> SocketPro provides bi-directional asynchronous real-time notification
>> service as shown
>
> Using their SuperTCP channel gives you full bi-directional communication.
> All calls over that channel are threaded and you can have multiple threads
> using a single SuperTCP channel simultaneously. They have various
> asynchronous channels as well.

Could you tell me where RemObjects supports real-time notification service?
I don't know SuperTCP. However, I know that RemObjects provides the
event EventReceiver.OnPollIntervalChanged Event. As its name implies,
RemObjects can't do any real-time notification at all. Our SocketPro bas
built-in real-time notification service at
http://www.udaparts.com/document/articles/chatservice.htm.

Contrary to your imagination, our SocketPro does NOT use threads for
asynchronous commuinication at all. Instead, our SocketPro uses 100%
non-blocking socket for asynchronous communication. Because SocketPro does
not use worker threads for cross-machine or -process communication, it has
much less thread context switches in comparison to threading approach.

SocketPro privides two sets of methods to notify other clients in real-time
fashion. One set of methods is used on client side, the other set on server
side. All of them can be asychronously called in batch without using any
threads at all.

>
>> 3. RemObjects use blocking socket for communication, but SocketPro
>> uses
>
> Again, that completely depends on the channel that you chose to use when
> using RemObjects. The HTTP channel is blocking yes - but they have Async
> channels as well.
>
>> I am not sure if you understand the above code. Please take a little
>> while to analyze the above "strange code", and try your best to
>> understand
>
> Looks quite nice - quite like the asynchronous calling of Delegates and
> the similar WaitAll() method when calling these asynchronously.

On the surface, our SocketPro asynchronous calls are similar to asynchronous
calling of Delegates. However, they both are very different.

With SocketPro, you can do batching requests, but you can NOT batch requests
with .NET Delegates. With SocketPro asynchronous calls are NOT involved with
threads, but asynchronous calling of Delegates .NET will require
involvements of threads. Batching requests is one of key features in
SocketPro for performance.

>
>> It is SIGNIFICANTLY faster and more scalabler than ANY .NET remoting and
>
> I'm still not convinced that you or anyone else could be certain of that
> given that you don't actually have any tests or benchmarks to objectively
> measure this. If you are going to go making wild statements like that then
> back them up with some data.

See the performance test result at the site
http://www.udaparts.com/document/articles/fastsocketpro.htm. As you know, we
do not have performance data for other remoting frameworks.

>
>> I would like you to write a sample to challendge our SocketPro.
>
> Ah, now that would be your job! I'm not the one who made bold claims about
> my remoting framework being the greatest thing since sliced bread... Don't
> get me wrong, it might very well be but if you're going to go round saying
> it is you've got to have some muscle behind your punch.

Once again, see the site
http://www.udaparts.com/document/articles/fastsocketpro.htm. Welcome if you
take our offer in the last message.

[James Crosswell]

msgroup wrote:
> Because you say something for RemObjects, I downloaded this framework and
> had a quick glance at its documentation. I really can't find any where to
> metion SSL/TLS support in RemObjects. I may be wrong, but please let me know
> where its documentation says SSL/TLS support?

I'm not sure about the docs - using the HTTP channel you simply specify
the url as https://theurl/bin and voila... SSL. Not too sure about TLS
as I've never used it.

> Could you tell me where RemObjects supports real-time notification service?
> I don't know SuperTCP. However, I know that RemObjects provides the
> event EventReceiver.OnPollIntervalChanged Event.

Yes the Event Receivers allow you to communicate from the server back to
clients (behind firewalls) using non bi-directional channels, like HTTP.
However their SuperTCP channel supports full two way communication so
the server can send messages back to the client without the client
having to "poll" as is the case when using http.

In any case, your framework looks great. If I didn't already have one I
was using which was doing everything I wanted then I'm sure I'd take a
look at it. So as I said before, best of luck with that.

[Spam Catcher]

James Crosswell <ja...@microforge.net> wrote in news:eSzD02MQHHA.1240
@TK2MSFTNGP03.phx.gbl:

> Thanks, I'm not actually looking for alternatives. The framework I'm
> using is fast and reliable. Best of luck though.

Do you know of any other remoting frameworks?

RemObjects
Geniune Channels
Socket Pro

Any other major ones out there?

[msgroup]

Hi, James:

Thanks a lot for your encouragement!

Regards,

"James Crosswell" <ja...@microforge.net> wrote in message

news:e$YhkHORH...@TK2MSFTNGP06.phx.gbl...

[James Crosswell]

None that I know of no (other than .NET remoting itself of course). If
none of those tickles your fancy then I guess you could drop back to
using raw sockets but that would seem pretty extreme to me, unless you
have some very particular requirements.

[msgroup]

Hi, James:

We have posted a large number of messages across many discussion groups.
As long as you pay somewhat attention to these post messages, you'll find
our SocketPro is able to solve many features that .NET remoting can't
provide at all.

Additionally, our SocketPro solves many complex problems listed in the
following:

Multi-threading -- You will NOT see any multi-threading related problems
on both client and server sides with SocketPro.
Performance and scalability -- You'll NEVER find any case that .NET
remoting is faster than our SocketPro. Our SocketPro is able to support many
more connections than .NET remoting.
Batching -- You can never do batching requests and returning results
with .NET remoting.
Transferring large set of objects or large data -- You will be very
confident with our SocketPro for transferring large set of objects or large
data.
Client window user interface -- You'll find that SocketPro for window
graphical user interfaces are never frozen for all types of networks.
PocketPC and Smartphone -- All of MS win32 platforms are fully supported
with the exactly same set of APIs. Therefore, you can directly reuse desktop
client application codes for devices applications. .NET remoting and coming
WCF do NOT support devices yet.

Other cool features with SocketPro:

1. Built-in security -- SSL/TLS fully supported with our own security
protocol plus custom authentication.
2. Built-in real-time bi-directional asynchronous message.
3. Cancel long-lasting requests without closing connections.
4. Built-in real-time compression supported.
5. Binary compatibility with great maintainability, modularity, version
control and extensibility
6. Lots of events.
7. Many others.

Cheers!

"James Crosswell" <ja...@microforge.net> wrote in message

news:e$YhkHORH...@TK2MSFTNGP06.phx.gbl...

[alexgrty]

Have a look
Fast Serialization and remoting
www.dotnetremoting.com

EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com