locked
UDP multicast being affected by listeners RRS feed

  • Question

  • Hi

     

    I have been using the UDP sample from the WCF SDK to multicast data contracts.

    The operation contract is one-way and I'm using a binary encoding.

    I just noticed something strange: the sender (client) is sending data 25% slower when there is a listener (service).

    From what I know of UDP multicast/broadcast it should not be affected at all by listeners.

    Is there some kind of additional data exchanged enforced by the WCF?

     

    Thanks

    Tuesday, April 29, 2008 8:28 AM

Answers

  • My bad.

    Turns out the results were being affected from both apps residing on the same computer.

    Once I seperated them to 2 computers the client kept sending data at the same rate with or without the service listening.

    I'm still curios: what did you mean by "this isn't acting like UDP multicast should.  But this is because it's really SOAP over UDP, so it tries to do UDP, but still adheres to a SOAP standard."?

    Thursday, May 1, 2008 6:14 AM

All replies

  • I'm not familiar with that sample, but I can say that if the listener is a WCF service, and there's an operation contract, then the transport is better defined as SOAP over UDP.  If you just have a raw listener, and no WCF, then you shouldn't notice a slowdown.

     

    The slowdown is because the WCF service acks the message it receives.  I'm not sure, but maybe adding the attribute,

    [OperationContract (IsOneWay = true)]

    to the operation would speed things up.

     

    From the page about the IsOneWay property:

    If the IsOneWay property is set to false (the default), even methods that return void result in a reply message. In this case, the infrastructure creates and sends an empty message to indicate to the caller that the method has returned. (Using this approach enables the infrastructure to send SOAP faults back to the client.) Setting IsOneWay to true is the only way to cancel the creation and dispatch of a response message.

     

    I'm not sure if that applies to UDP, though.  Let me know if that speeds things up.

     

    -James

    Tuesday, April 29, 2008 10:26 PM
  • Hi James
    As I wrote in the original message, I am using the IsOneWay attribute, so this is not the problem.
    Wednesday, April 30, 2008 5:41 AM
  • Okay, then I don't think there is any way to speed things up using a WCF listener.  The only other thing I can think of that might speed things up would to use async calls to send the messages.

     

    (FYI: I've seen "Using one way" take on one of three meanings: using service operations which don't return, using a OneWayBindingElement, or using the IsOneWay attribute.  I wasn't absolutely sure which you meant.)

     

     

    -James

    Wednesday, April 30, 2008 4:04 PM
  • Ok, I stand corrected - I meant IsOneWay.

    But still: the thing that alarms me is it seems the client is affected by the service existence, and from what I know about UDP multicast this is wrong.

    Wednesday, April 30, 2008 6:40 PM
  • And I agree with you, this isn't acting like UDP multicast should.  But this is because it's really SOAP over UDP, so it tries to do UDP, but still adheres to a SOAP standard.  So it's slower when connecting to a WCF service as opposed to broadcasting to a non-ServiceModel listener.  If you use this client to interop with non-WCF services, the slow-down shouldn't happen.

     

    -James

     

    Wednesday, April 30, 2008 6:45 PM
  • My bad.

    Turns out the results were being affected from both apps residing on the same computer.

    Once I seperated them to 2 computers the client kept sending data at the same rate with or without the service listening.

    I'm still curios: what did you mean by "this isn't acting like UDP multicast should.  But this is because it's really SOAP over UDP, so it tries to do UDP, but still adheres to a SOAP standard."?

    Thursday, May 1, 2008 6:14 AM
  • I was having a conversation with our WCF UDP test owner about this.  He mentioned that the WCF implementation isn't completely and soley UDP, since it uses WCF, but just has UDP at the transport layer.  I think he meant that the packets would be larger, since the message is a SOAP, but UDP doesn't require SOAP for transport. 

     

    -James

     

    Thursday, May 1, 2008 4:06 PM
  • No, there isn't, unless you have additional elements in your channel stack (for example, a security channel).

     

    Soap over UDP defines a standard for request-reply and duplex message exchanges over UDP, if your client code performs such a message exchange, it might incur additional overhead listening for messages.  But in a simple one-way contract, the performance shouldn't be affected by the existence of a listener.

     

    Thursday, May 1, 2008 6:31 PM
  • Hi Dotmad,

     

    Could you please explain in details how to make UDP sample multicast ?

    Saturday, May 3, 2008 10:04 AM
  • Thanks James

     

    As I wrote I'm not getting the same problem while using two computers, but I'm still bothered by performance - I manage to send/receive about 20000 objects (not a very complex class) per second, and if my memory is right, I can get better perf using TCP. Since UDP should be more efficient than TCP (since it's not a two way conversation) this may indicate a problem I'm still having.

    I have been using the GZip encoder to increase the number of object sent in a single message (as the fixed UDP packet size causes exception if the message becomes too big).

    Below you can find my configuration, any comments regarding it?

     

    (Roman, feel welcome to take a look at the app.config, and I'll probably write a blog post on the subject soon)

     

     

     

     

     

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <system.serviceModel>
          <behaviors>
            <endpointBehaviors>
              <behavior name="UDPBehavior">
                <dataContractSerializer ignoreExtensionDataObject="true" maxItemsInObjectGraph="5242880" />
              </behavior>
            </endpointBehaviors>
          </behaviors>
          <extensions>
            <bindingElementExtensions>
              <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />
              <add name="gzipMessageEncoding" type="Microsoft.ServiceModel.Samples.GZipMessageEncodingElement, GZipEncoder, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            </bindingElementExtensions>
            <bindingExtensions>
              <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />
            </bindingExtensions>
          </extensions>

          <client>
            <endpoint address="soap.udp://225.225.0.1:2222/TargetObserver/"
              behaviorConfiguration="UDPBehavior" binding="customBinding"
              bindingConfiguration="DatagramServer" contract="DataContracts.ITargetObserver"
              name="TargetsClientService" />
          </client>

          <bindings>
            <customBinding>
              <binding name="DatagramServer">
                <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" />
                <!--<binaryMessageEncoding></binaryMessageEncoding>-->
                <udpTransport maxMessageSize="655360"
                  multicast="true" />
              </binding>
            </customBinding>
          </bindings>
        </system.serviceModel>
    </configuration>

    Saturday, May 3, 2008 7:54 PM
  • Hi Dotmad,

     

    Thanks for your help.

    Could you please also post the server side confgiuration.

    Monday, May 5, 2008 1:52 PM
  • Hi Roman

    Sorry for the long delay.

    You can find the full configuration here:

    http://dotmad.blogspot.com/2008/06/using-udp-multicast-channel-in-wcf.html

    Tuesday, June 10, 2008 12:14 PM
  • Hello Dotmad,

     

    Thank you very much for your help.

     

    BTW : Do you know why UDP binding is not official part of WCF framework ?

    Thursday, June 19, 2008 6:42 AM