As a VB.NET instructor and a guy who does most of his consultancy in C# I
can totally agree with Ian that there are NO differences between C# and
VB.NET when it comes to coding at the socket level.
If you use System.Net instead of .NET remoting you will get better
performance, simply because (as Ian said, you're closer to the metal). .NET
remoting uses sockets under the covers and tries to increase performance by
using cached buffers, sockets etc, but what you have to remember is that
it's doing considerable amounts of serialization AND using reflection to
instantiate the remote object.
The System.Net classes will allow you to do everything you can do in .NET
remoting and more: for example UDP, IP multicasting and even the
serialization of object references!
Performance on the server is critical and you'll need to make it
multithreaded. The System.Net sockets have BeginXXX and EndXXX methods,
allowing sockets to party along with the .NET synchronization patterns.
Make sure that you call BeginAcccept and pass the 'listening' (server)
socket as the 'state' parameter.
_listenerSocket.BeginAccept(new AsyncCallback( AcceptCallback ),
_listenerSocket);
The callback is shown below
protected void AcceptCallback(IAsyncResult ar)
{
Socket server = (Socket)ar.AsyncState;
Socket client = server.EndAccept(ar);
_clientHandler.BeginInvoke(client, null, null);
server.BeginAccept(new AsyncCallback( AcceptCallback ), server);
}
Note that the listen socket is used to call EndAccept and then another
thread is issued to 'handle' the request. The code then sets the server to
listen for further connections. Make sure you match every BeginXXX with an
EndXXX - one way MT requests aren't guaranteed to cleanup correctly -
remember sockets are unmanaged resources!
Hope this helps
A
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Griffiths
Sent: 24 July 2004 14:57
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Client IP Address
> I'm also getting a very strong impression that multithreaded
> listeners are best implemented in C#.
Speaking as someone who much prefers C# to VB.NET, I don't actually
agree. I'm not aware of anything C# can do that makes it more able to
implement a multithreaded listener than VB.NET - the same set of CLR
services are available to you.
I would choose C# if I were writing it simply because I know C# much
better than VB.NET. If you know VB.NET better, it's probably better to
go with VB.NET.
> I'm particularly focused on stability, scalability and
> performance (who isn't?), and suspect the rewrite should be
> from the socket level rather than TcpClient.
It's true that to achieve the best possible throughput you're almost
certainly better of working directly with sockets, simply because you
are working closer to the metal. But I've not done any performance
tests to see how much difference it would make. (And this of course is
a decision you can make independently of language.)
--
Ian Griffiths - DevelopMentor
http://www.interact-sw.co.uk/iangblog/
===================================
This list is hosted by DevelopMentor. http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
