Re: Events between machines

From: Ingo Rammer (ingorammer_at_online.nospam)
Date: 12/18/04 

Date: Sat, 18 Dec 2004 15:04:44 +0100

Hi Magne,

The problem with UDP is that it is generally not reliable. Even if no
fragmentation occurs, you might still loose some events. (Or you might even
loose a lot of events, if you are for example running on a WLAN.) This
doesn't necessarily mean that UDP is bad ... this behavior is perfectly ok
for a lot of applications. One just as to design the app in a way that it
would also work if no single event would ever reach the clients. [as a
possible but unlikely edge case]

If you need reliable delivery of events, I'd suggest to go for MSMQ instead.
In this case, you can create one client-side queue on each client machine
(as a private queue ... it doesn't need to be in the Active Directory.)

Of course you need to install MSMQ on your client's machines first as it is
an optinal component of Windows.

The server can then use a feature of MSMQ 3.0 (if you run on Windows XP or
Windows Server 2003) which allows you to send a message to multiple
destination queues at the same time without relying on IP multicasting. You
can simply specify more then one destination by separating them with ","
(comma).

A valid path name is for example
"FormatName:direct=os:client01\private$\testqueue,os:client01\private$\testqueue"

I've attached the source code for a small client and a small server to this
post. (If you need additional delivery guarantees, you can enable durability
of messages.)

Please note: Before using this sample in production environments, you should
decide on a time-to-live for every message. Otherwise some outgoing queues
might collect a multitude of messages which will - at some point in time -
make your server rather slow (err ... as in "non-workingly slow"). You can
set the message's TimeToReachQueue property accordingly.

Cheers,
-Ingo

thinktecture
http://www.thinktecture.com
In-depth support and consulting for software architects and developers

"Magne Ryholt" <magne.ryholt@bluezone.no> wrote in message
news:OSLAeEQ5EHA.1264@TK2MSFTNGP12.phx.gbl...
> Div. articles (e.g. Ingo Rammer
> http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html)
> concludes with the advice: Don't use events (callback) between machine,
> even
> in an intranet environment.
>
> Assume one server and several clients, all on the same subnet (datalayer
> is
> 100Mb ethernet)..
> The server wants to update the clients with *something*, but don't want to
> use callback.
>
> Assume the server send small udp packets without actual data, but with
> info.
> regarding how the clients (which are listening for these udp packets)
> could
> get the changed, actual data from the server by using *normal* method
> calls
> with return values.
> It is not neccessary for the server to know if the clients receive these
> packets, it is nothing it can do about it anyway.
>
> This way callbacks could be avoided, however a little extra overhead is
> introduced and an extra thread is needed on the clients.
> To make it working simple, the UDP packet should not be fragmented.
>
> Any comments on this approach ? Reliability ?
> How to make sure that udp packets are not fragmented ? Is there any
> managed
> or unmanaged method returning the MTU ?
>
>

begin 666 Sender.cs
M=7-I;F<@4WES=&5M.PT*=7-I;F<@4WES=&5M+E1E>'0[#0IU<VEN9R!3>7-T
M96TN0V]L;&5C=&EO;G,[#0IU<VEN9R!3>7-T96TN365S<V%G:6YG.PT*#0IC
M;&%S<R!396YD97(-"GL-"B @<W1A=&EC('9O:60@36%I;BAS=')I;F=;72!A
M<F=S*0T*("![#0H@(" @0V]N<V]L92Y7<FET92@B16YT97(@4W1R:6YG('1O
M(&)R;V%D8V%S=#HB*3L-"B @("!3=')I;F<@<W1R(#T@0V]N<V]L92Y296%D
M3&EN92@I.PT*#0H@(" @07)R87E,:7-T(&-L:65N=',@/2!N97<@07)R87E,
M:7-T*"D[#0H@(" @8VQI96YT<RY!9&0H(FQO8V%L:&]S="(I.PT*(" @(&-L
M:65N=',N061D*")I;F=O>#,Q(BD[#0H-"B @(" O+R B9&ER96-T/6]S.FQO
M8V%L:&]S=%QP<FEV871E)%QT97-T<75E=64L;W,Z:6YG;W@S,5QP<FEV871E
M)%QT97-T<75E=64-"B @("!3=')I;F<@9F]R;6%T3F%M92 ]($)U:6QD1F]R
M;6%T3F%M92AC;&EE;G1S*3L-"B @("!-97-S86=E475E=64@<75E(#T@;F5W
M($UE<W-A9V51=65U92AF;W)M871.86UE*3L-"@T*(" @($UE<W-A9V4@;7-G
M(#T@;F5W($UE<W-A9V4H*3L-"B @("!M<V<N1F]R;6%T=&5R(#T@;F5W($)I
M;F%R>4UE<W-A9V5&;W)M871T97(H*3L-"B @("!M<V<N0F]D>2 ]('-T<CL-
M"B @("!Q=64N4V5N9"AM<V<I.PT*#0H@(" @0V]N<V]L92Y296%D3&EN92@I
M.PT*("!]#0H-"B @<W1A=&EC('-T<FEN9R!"=6EL9$9O<FUA=$YA;64H07)R
M87E,:7-T(&-L:65N=',I#0H@('L-"B @("!I9B H8VQI96YT<RY#;W5N=" ]
M/2 P*2 -"B @(" @('1H<F]W(&YE=R!!<F=U;65N=$5X8V5P=&EO;B@B3&ES
M="!O9B!C;&EE;G1S(&5M<'1Y+B(L(")C;&EE;G1S(BD[#0H-"B @("!3=')I
M;F="=6EL9&5R(&)L9" ](&YE=R!3=')I;F="=6EL9&5R*"D[#0H@(" @8FQD
M+D%P<&5N9"@B1F]R;6%T3F%M93HB*3L-"B @("!F;W)E86-H("A3=')I;F<@
M8VQI(&EN(&-L:65N=',I#0H@(" @>PT*(" @(" @8FQD+D%P<&5N9"@B9&ER
M96-T/6]S.B(I.PT*(" @(" @8FQD+D%P<&5N9"AC;&DI.PT*(" @(" @8FQD
M+D%P<&5N9"@B7%QP<FEV871E)%Q<3D]4249)0T%424].4R(I.PT*(" @(" @
M8FQD+D%P<&5N9"@B+"(I.PT*(" @('T-"B @("!B;&0N4F5M;W9E*&)L9"Y,
M96YG=&@M,2PQ*3L-"B @("!R971U<FX@8FQD+E1O4W1R:6YG*"D[#0H@('T-
$"GT-"@``
`
end

begin 666 Receiver.cs
M=7-I;F<@4WES=&5M.PT*=7-I;F<@4WES=&5M+DUE<W-A9VEN9SL-"@T*8VQA
M<W,@4F5C96EV97(-"GL-"B @<W1A=&EC('9O:60@36%I;BAS=')I;F=;72!A
M<F=S*0T*("![#0H@(" @4W1R:6YG('%U975E;F%M92 ]($ B+EQP<FEV871E
M)%Q.3U1)1DE#051)3TY3(CL-"@T*(" @(&EF("@A365S<V%G95%U975E+D5X
M:7-T<RAQ=65U96YA;64I*0T*(" @('L-"B @(" @($UE<W-A9V51=65U92Y#
M<F5A=&4H<75E=65N86UE*3L-"B @("!]#0H-"B @("!-97-S86=E475E=64@
M<75E(#T@;F5W($UE<W-A9V51=65U92AQ=65U96YA;64I.PT*(" @('%U92Y&
M;W)M871T97(@/2!N97<@0FEN87)Y365S<V%G949O<FUA='1E<B@I.PT*#0H@
M(" @=VAI;&4@*'1R=64I#0H@(" @>PT*#0H@(" @("!U<VEN9R H365S<V%G
M92!M<V<@/2!Q=64N4F5C96EV92@I*0T*(" @(" @>PT*(" @(" @("!3=')I
M;F<@<W1R(#T@*%-T<FEN9RD@;7-G+D)O9'D[#0H@(" @(" @($-O;G-O;&4N
M5W)I=&5,:6YE*")296-E:79E9#H@>S!](BP@<W1R*3L-"B @(" @('T-"B @
/("!]#0H@('T-"GT-"@T*
`
end

Relevant Pages

  • Re: Example: VMS to Web Browser "push" technology
    ... to all clients that subscribe to a particular IP address. ... Was there some special reason to use UDP? ... There is no benefit in maintaining a persitent connection between client ... and server because who's to say that you'll want to visit that same server ...
    (comp.os.vms)
  • Re: Events between machines
    ... > destination queues at the same time without relying on IP multicasting. ... > I've attached the source code for a small client and a small server to ... >> Assume one server and several clients, all on the same subnet (datalayer ... >> regarding how the clients (which are listening for these udp packets) ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: SOAP applicable in this scenario ?
    ... SOAP is an expensive protocol, I don't know how many UDP packets per ... When all your clients run a SOAP server, you can push the SOAP envelopes ...
    (comp.lang.java.programmer)
  • Re: Outlook and Exchange2003 question
    ... to interfere with new mail notifications and folder refreshes. ... caused by a UDP datapacket not reaching the workstation from the server. ... routing UDP, clients behind NAT and server on public side, .etc) ...
    (microsoft.public.outlook.general)
  • Events between machines
    ... Don't use events (callback) between machine, ... Assume one server and several clients, all on the same subnet (datalayer is ... Assume the server send small udp packets without actual data, ...
    (microsoft.public.dotnet.framework.remoting)