Client/Server Rendezvous on the LANby Shawn Van Ness
04/14/2003
You.
Background.
Client-Server Rendezvous, on a Budget.
Security First!.
Multicast Vs. Broadcast!
Client-Server Rendezvous via UDP Multicast();
Conclusion
Showing messages 1 through 12 of 12.
- Having multiple ServicePublisher on one pc not possible
2004-09-01 05:29:45 DeepDiver [View]
- Having multiple ServicePublisher on one pc not possible
2004-09-01 06:32:28 DeepDiver [View]
SOLUTION:
in the ServiceProvider use AdvUdpClient instead of UdpClient
impl for AdvUdpClient:
public class AdvUdpClient : System.Net.Sockets.UdpClient
{
public AdvUdpClient( int port )
{
this.Client.SetSocketOption(SocketOptionLevel.Socket,SocketOptionName.ReuseAddress,1);
this.Client.Bind( new IPEndPoint(IPAddress.Any, port) );
}
}
- multiple network interface
2004-05-10 06:38:56 ghasempour [View]
I have multiple network interface on a system, and
there was a problem about rendezvous multicast.
that system can not receive any packet from server
and also other systems can not receive any packet
from it.
what is the problem?
- Update for .NET v1.1
2003-07-16 22:34:17 arithex [View]
To workaround the unhandled SocketException crash on the client-side, when running under the v1.1 runtime, uncomment the two lines in UdpRendezvous.cs which handle the SocketException (lines 331-332).
Explanation:
- Re: Rendezvous
2003-06-30 01:23:57 anonymous2 [View]
Tibco has a product called Rendezvous
that pretty much does the same thing,
only that it is also secure, robust, and
costs a lot!
- Open systems...
2003-05-27 12:05:00 anonymous2 [View]
I don't discuss that "multicast" is a technology offered by most of the operating systems (not specific of ".NET"), that developers need to be aware of, and this article could have been a good example.
But it was called "Client/server renderzvous on the LAN" (and for me, the "LAN" is not only for the .NET platform).
The article unfortunately included this statement:
// Send response (our guid, followed by serialized endpoint info)
this.listener.Send(this.response, this.response.Length, callerEndpoint);
And with .NET, this probably will be represented with a binary M$ representation on the callerEndpoint info collection, that I doubt it could be easily deserialized by other platforms (so it could be difficult to interoperate with it).
This article may become a bad reference for other developers, that may be "inspired" with it, and that will produce "closed" systems.
Now comes the moral of the tale: you can read the article to learn about multicast communications (and more?), but forget the final objective (= the title).
Finally, I don't want to judge the quantity of code of your examples.... I only want to say that standards allows development of open-source libraries (sometimes of great quality, very easy to use, and available for many computer languages, independly of the platform), and I hope that .NET platform applications & services will use the same standards.
- Re: Open systems...
2003-05-27 12:17:35 arithex [View]
This is great advice -- my use of BinaryFormatter to transmit endpoint information is very ill-advised... and this is not just a cross-platform/openness issue: it might even hamper interop between two Windows machines running different versions of .NET, because it relies on the private/internal layout of SortedList (or Hashtable, or whatever it was I used)!
Thanks for catching me on that.
-S
- good one
2003-05-15 08:15:59 anonymous2 [View]
I thought this was a good article. Not sure why the other posters are so annoyed that their pet "rendezvous" standards are not mentioned... this article just points out how this stuff works at the socket level, and how you can build quick-n-dirty broadcast-based rendezvous into your app with just a few lines of code and no external libraries.
I think this is a useful general technique that more developers need to be aware of. Thanks for the article.
- Link to sample source code
2003-05-06 18:52:23 arithex [View]
The link from ONDotNet seems to be broken, at the moment...
The code in Listing 1 can be found here, along with sample client and server apps, as UdpRendezvous.cs:
-S
- OpenSLP, Apple Rendezvous, et. al.
2003-05-06 18:43:49 arithex [View]
Thanks for the tips on OpenSLP and Apple Rendezvous, folks -- these technologies are outside my limited Windows-centric experience, so of course I failed to mention them.
But still, I'm not quite convinced -- what features/benefits do they bring to the table, that simple IGMP multicasting doesn't provide?
Reinventing the wheel is almost always a bad thing, but would I really be able to reuse either of those wheels with less code than in Listing 1? And without any awkward runtime dependencies or license-baggage?
The point of this article is that everything you need to accomplish simple client/server rendezvous on the LAN is provided with .NET, out of the box.
Open Source? Heck, Listing1.cs is public domain!
-S
- Please, don't use (neither define), more propietary protocols!
2003-04-23 10:44:24 anonymous2 [View]
Once a time, there was a "standard" protocol called "Service Location Protocol" (or "SLP", for the friends), that was designed for this purpose. There also were some implementations for it (that were open-source, secure, and ran stable & interoperable on many platforms, like "OpenSLP.org"), and useful client libraries for many languages (maybe with the exception of some immature platforms like .NET, isn't?).
But they were all free, and anybody liked to use them, because they preffered to get the extraordinary support of commercial vendors.
So they soft-disappeared between the micro-time doors.
- The rendezvous problem is partially your use of the word rendezvous!
2003-04-23 05:23:05 anonymous2 [View]
[This is known as the "rendezvous" problem...]:
Only one usage of each socket address (protocol/network address/port) is normally permitted
this happens in line 72
while calling :
this.listener = new UdpClient(UdpMulticastGroupSettings.ServerPort);
any solution on this available?