Asynchronous socket programming vs. remoting

[Michael Lindsey]

I need to write a server app to send images to client GUIs that are outside
of the server's domain.
The client will have the file system path to the image but can not access
the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.

I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is difficult
to code.

I'd like to get
1. a recommendation on remoting vs socket programming for what I'm doing
and
2. If socket programming is recommended ... the url of a full sample of
an ansychronous server\client file sharing application.

Thank you,
Michael Lindsey

[Wilfried Mestdagh]

Hello Michael,

I cannot give you a recommandation on what is for your solution the best,
because I just started with .NET. But I can give you example of client /
server using TCP using asynchronous written in Delphi 8. You can email me on
wi******@mestdagh.biz

rgds, Wilfried
http://www.mestdagh.biz

[Wilfried Mestdagh]

Hello Michael,

I just picked this up from another thread: "Remoting is for when you want to
execute code, but execute it on another ('remote') machine"

So I think Remoting is a kind of Middleware. So I think in your case TCP is
the way to go.

rgds, Wilfried
http://www.mestdagh.biz

[Michael Lindsey]

Thanks for the replies.
I know what both technologies are. I have written a prototype using
remoting.
But don't have the experience to choose between the two.
I'm looking for recommendations from someone who has experience in remoting
or using a tcp server for a similar architecture.

I'd really like to hears the pros and cons of both options from someone that
has the experience. I have read about the pros and cons for both
technologies from a theoretical perspective.

Thank You,
Michael Lindsey
"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:FJ**************@fe39.usenetserver.com...

I need to write a server app to send images to client GUIs that are outside of the server's domain.
The client will have the file system path to the image but can not access
the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.

I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is difficult to code.

I'd like to get
1. a recommendation on remoting vs socket programming for what I'm doing and
2. If socket programming is recommended ... the url of a full sample of an ansychronous server\client file sharing application.

Thank you,
Michael Lindsey

[William Stacey [MVP]]

You have another option that could be good for you - WSE web services.
You can leverage the parm passing and security of wse and use DIME to
transfer your files.
The big issue with Remoting is versioning. As it is strongly typed against
your objects, you have
to change the clients every time you want to remotable types on the server
and visa-versa.
Because wse is soap/xml based, you have a lot more flexability in that
regard. wse also supports tcp, so you can create a tcp based client/server
solution and host it in a service or stand-alone app, etc.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:FJ**************@fe39.usenetserver.com...

I need to write a server app to send images to client GUIs that are outside of the server's domain.
The client will have the file system path to the image but can not access
the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.

I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is difficult to code.

I'd like to get
1. a recommendation on remoting vs socket programming for what I'm doing and
2. If socket programming is recommended ... the url of a full sample of an ansychronous server\client file sharing application.

Thank you,
Michael Lindsey

[Frank Hileman]

Hello Michael,

I have tried web services, remoting, and direct tcp/ip. Of the three I
prefer tcp/ip (sockets):

- web services are incredibly slow. This is not suprising, considering the
xml processing. But it can go through a firewall. This would be the last
choice for me. Useless for real-time data. In your case, you would have
several layers of overhead: not just the http and xml parsing, but
additionally conversion to and from base64 encoding. I imagine both your
client and server will perform horribly.

- remoting is ok but not as fast as tcp/ip. The other problem is the strong
typing -- you must have a copy of the remoted types on both machines.

- .NET has fairly good support for simple tcp/ip. Performance is great. You
do not need the same assembly on the client and server. Instead, you create
your own protocol, whereby you decide beforehand on the encoding and order
of data. Of the three this is the best, and in many ways the simplest, but
you need an open port.

I don't have a copy of a file sharing program. There is a basic TCP/IP
real-time data communication and visualization program included in the
VG.net samples, under the title Sockets. It uses asynchronous functions in
..NET correctly; not using a separate thread per client, but rather the
functions (BeginWrite/EndWrite/BeginRead/EndRead) that make use of the
thread pool. TCP/IP programming this way is easy. Avoid online samples that
create a separate thread per-client, or try to roll their own thread pool
from scratch. This is not necessary.

Regards,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:FJ**************@fe39.usenetserver.com...

I need to write a server app to send images to client GUIs that are outside
of the server's domain.
The client will have the file system path to the image but can not access
the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.

I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is
difficult
to code.

I'd like to get
1. a recommendation on remoting vs socket programming for what I'm
doing
and
2. If socket programming is recommended ... the url of a full sample of
an ansychronous server\client file sharing application.

Thank you,
Michael Lindsey

[Michael Lindsey]

Thanks Frank.
You are the first person that said I should use sockets.
The argument against sockets is usually "all the coding and maintenance"
that it takes to get it working well.
I decided to give it a try and got a real nice solution up and running
quickly, with surprisingly little code, using asynchronous network streams.
The performance is awesome! I am pulling images from FL to GA and loading
them quicker than I can load them from my harddrive using the file system.

It scales nice too - I tried throwing 400 requests at the server in a span
of 30 secs and it returned all images without a hitch.
I was pulling them at 129kb/s and that limitation is likely due to using DSL
over a VPN.
The processor usage during my test never went above 8% on a Pentium II 500
with 1 gig of ram.
The ram usage was at 10 mb but dropped back down to 2-3 mb after each test.
The threads got up around 100 during the test and dropped back down to 6
after the test. The extra threads were due to the asynchronous processing
and it was all handled by the system. I didn't have to create a single extra
thread manually.

Thanks for the advice.

Michael Lindsey

"Frank Hileman" <fr******@no.spamming.prodigesoftware.com> wrote in message
news:ui**************@TK2MSFTNGP09.phx.gbl...

Hello Michael,

I have tried web services, remoting, and direct tcp/ip. Of the three I
prefer tcp/ip (sockets):

- web services are incredibly slow. This is not suprising, considering the
xml processing. But it can go through a firewall. This would be the last
choice for me. Useless for real-time data. In your case, you would have
several layers of overhead: not just the http and xml parsing, but
additionally conversion to and from base64 encoding. I imagine both your
client and server will perform horribly.

- remoting is ok but not as fast as tcp/ip. The other problem is the strong typing -- you must have a copy of the remoted types on both machines.

- .NET has fairly good support for simple tcp/ip. Performance is great. You do not need the same assembly on the client and server. Instead, you create your own protocol, whereby you decide beforehand on the encoding and order
of data. Of the three this is the best, and in many ways the simplest, but
you need an open port.

I don't have a copy of a file sharing program. There is a basic TCP/IP
real-time data communication and visualization program included in the
VG.net samples, under the title Sockets. It uses asynchronous functions in
.NET correctly; not using a separate thread per client, but rather the
functions (BeginWrite/EndWrite/BeginRead/EndRead) that make use of the
thread pool. TCP/IP programming this way is easy. Avoid online samples that create a separate thread per-client, or try to roll their own thread pool
from scratch. This is not necessary.

Regards,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:FJ**************@fe39.usenetserver.com...

I need to write a server app to send images to client GUIs that are outside of the server's domain.
The client will have the file system path to the image but can not access the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.

I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is
difficult
to code.

I'd like to get
1. a recommendation on remoting vs socket programming for what I'm
doing
and
2. If socket programming is recommended ... the url of a full sample of an ansychronous server\client file sharing application.

Thank you,
Michael Lindsey

[Frank Hileman]

That's great! Yes, .NET makes basic scalable tcp/ip easy. You don't need a
lot of code. We just have one small file each for the client and server --
about 2 pages of code, I would say.
- Frank
"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:ON***********@fe39.usenetserver.com...

Thanks Frank.
You are the first person that said I should use sockets.
The argument against sockets is usually "all the coding and maintenance"
that it takes to get it working well.
I decided to give it a try and got a real nice solution up and running
quickly, with surprisingly little code, using asynchronous network
streams.
The performance is awesome! I am pulling images from FL to GA and loading
them quicker than I can load them from my harddrive using the file system.

It scales nice too - I tried throwing 400 requests at the server in a span
of 30 secs and it returned all images without a hitch.
I was pulling them at 129kb/s and that limitation is likely due to using
DSL
over a VPN.
The processor usage during my test never went above 8% on a Pentium II 500
with 1 gig of ram.
The ram usage was at 10 mb but dropped back down to 2-3 mb after each
test.
The threads got up around 100 during the test and dropped back down to 6
after the test. The extra threads were due to the asynchronous processing
and it was all handled by the system. I didn't have to create a single
extra
thread manually.

Thanks for the advice.

Michael Lindsey

[Ravichandran J.V.]

Remoting is an infrastructure. it relieves you with all the
responsibilities regarding serialization etc. With Asynchronous
programming, you will be required to implement the formatters,
serializations and marshalling by yourself. It is not such a good idea
to adopt async.programming when you have a functional infrastructure
provided for free in Remoting.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Frank Hileman]

For communication of a simple protocol and simple sets of primitives (ints,
doubles, byte arrays) I have found basic tcp/ip easier. There is no need for
marshalling or serialization in these cases. You simply write your data to a
memory stream. You only have to create your own protocol.

Remoting brings its own set of headaches to the table.

- Frank

"Ravichandran J.V." <jv************@yahoo.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Remoting is an infrastructure. it relieves you with all the
responsibilities regarding serialization etc. With Asynchronous
programming, you will be required to implement the formatters,
serializations and marshalling by yourself. It is not such a good idea
to adopt async.programming when you have a functional infrastructure
provided for free in Remoting.