Re: Asynchronous socket programming vs. remoting

From: Michael Lindsey (mike_lindsey_at_alltel.net)
Date: 11/16/04 

Date: Tue, 16 Nov 2004 15:50:27 -0500

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" <frankhil@no.spamming.prodigesoftware.com> wrote in message
news:uiJWIeyyEHA.2600@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" <mike_lindsey@alltel.net> wrote in message
> news:FJBld.966$Tu.834@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
> >
> >
> >
>
>

Relevant Pages

  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... client ... No bollocks HTTP, SOAP, XML, Java, Garbage ... receive messages from any number of server processes who in turn could be ... Unlike TCP/IP and/or UDP Sockets with Java that have been around since ...
    (comp.os.vms)
  • Re: Emulating I/O Completion Port on Win98.
    ... or for GUI programs - use async I/O ... > My Client is an FTP Client and I thought emulating IOCP would be the best ... > solution under Win98 to quickly copy a big file from the FTP Server. ... >>> monitor thread created dedicates to check the IO status of the sockets ...
    (microsoft.public.win32.programmer.networks)
  • Re: Asynchronous socket programming vs. remoting
    ... The client starts up and requests a batch of images to data enter. ... can download the image directly from the file system. ... I am planning on using remoting or tcp server to get around this issue. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Emulating I/O Completion Port on Win98.
    ... server, not client? ... If you client behave as a server to other client you do can use IOCP too, ... > 1) How many sockets should be in the list? ...
    (microsoft.public.win32.programmer.networks)
  • Re: another sockets library
    ... Currently it is C, only, but platform independant (works on Windows, Mac ... There is a server and client example. ... I've seen this remark about Windows sockets and selecta few times ...
    (comp.lang.lisp)