Comet implementation in WCF

Discussion in 'ASP .Net Web Services' started by Jonny Bergdahl, Nov 19, 2008.

  1. I am developing a WCF Comet web service, where client requests gets queued
    until a response is available. The connection to the client is thus open a
    long time, and in the Comet pattern timeouts is a factor that needs to be
    addressed. It can for instance be a proxy server between the client and
    server that has a short timeout that disconnects before the server or
    client.

    Now, the question is how to get a handle to the response so that I can check
    if the client is still connected?

    Regards;
    /jb
     
    Jonny Bergdahl, Nov 19, 2008
    #1
    1. Advertising

  2. Jonny Bergdahl

    Steven Cheng Guest

    Hi Jonny,

    As for the WCF Comet service scenario you mentioned, I think what you need
    now is some means to check the client connection status when the
    server-side finished the method(and ready to return).

    So far based on my research, at server-side, WCF method can use
    "OperationContext.Current" to inspect some WCF method invocation context
    info. And the OperationContext class has a "InstanceContext" property that
    can help inspect the current communication object's State:

    #OperationContext Class
    http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontext
    .aspx

    For example:

    ========================
    public string GetStringData()
    {

    OperationContext.Current.InstanceContext.State
    }
    ========================

    BTW, since your server-side WCF operation will take long time to process,
    have you used async method call pattern at client-side? I think using async
    approach will make the client-side UI responding perform better.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    Delighting our customers is our #1 priority. We welcome your comments and
    suggestions about how we can improve the support we provide to you. Please
    feel free to let my manager know what you think of the level of service
    provided. You can send feedback directly to my manager at:
    .

    ==================================================
    Get notification to my posts through email? Please refer to
    http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

    Note: MSDN Managed Newsgroup support offering is for non-urgent issues
    where an initial response from the community or a Microsoft Support
    Engineer within 2 business day is acceptable. Please note that each follow
    up response may take approximately 2 business days as the support
    professional working with you may need further investigation to reach the
    most efficient resolution. The offering is not appropriate for situations
    that require urgent, real-time or phone-based interactions. Issues of this
    nature are best handled working with a dedicated Microsoft Support Engineer
    by contacting Microsoft Customer Support Services (CSS) at
    http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
    ==================================================
    This posting is provided "AS IS" with no warranties, and confers no rights.

    --------------------
    >From: "Jonny Bergdahl" <>
    >Subject: Comet implementation in WCF
    >Date: Wed, 19 Nov 2008 11:02:52 +0100


    >
    >I am developing a WCF Comet web service, where client requests gets queued
    >until a response is available. The connection to the client is thus open a
    >long time, and in the Comet pattern timeouts is a factor that needs to be
    >addressed. It can for instance be a proxy server between the client and
    >server that has a short timeout that disconnects before the server or
    >client.
    >
    >Now, the question is how to get a handle to the response so that I can

    check
    >if the client is still connected?
    >
    >Regards;
    >/jb
    >
    >
     
    Steven Cheng, Nov 20, 2008
    #2
    1. Advertising

  3. > now is some means to check the client connection status when the
    > server-side finished the method(and ready to return).


    Yes.

    > info. And the OperationContext class has a "InstanceContext" property that
    > can help inspect the current communication object's State:


    Seems to be exactly what I am looking for. I also notice that it has a
    Closing event that I can hook up to forward the disconnect directly to my
    service queue. That would mean that I have to store the InstanceContext
    along the request in my queue object. Is that valid?

    > BTW, since your server-side WCF operation will take long time to process,
    > have you used async method call pattern at client-side? I think using
    > async
    > approach will make the client-side UI responding perform better.


    I have used the async pattern on the server, all requests are moved to a
    separate thread that keeps a queue of the waiting clients. That way I won't
    exhaust the thread pool used to receive the requests, as we are designing
    for 500+ clients.

    The client on the other hand is a Windows service whose sole purpose is to
    wait for the service response, so there might not be a need to use the async
    pattern (depending on how I can process a service stop request).

    Regards;
    /jb
     
    Jonny Bergdahl, Nov 20, 2008
    #3
  4. Jonny Bergdahl

    Steven Cheng Guest

    Thanks for your reply Jonny,

    The "OperationContext" and "InstanceContext" should be available at least
    during the entire WCF method processing lifecycle. Also, generally if the
    code is within the same callstack/thread as the WCF's operation method, it
    can access the Instancecontext via OperationContext. If you switch to other
    threads(which is not synchronized with the main WCF operation method
    calling thread), it is not guranteed that you can access the
    operationContext.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    Delighting our customers is our #1 priority. We welcome your comments and
    suggestions about how we can improve the support we provide to you. Please
    feel free to let my manager know what you think of the level of service
    provided. You can send feedback directly to my manager at:
    .



    --------------------
    >From: "Jonny Bergdahl" <>
    >References: <#>

    <>
    >In-Reply-To: <>
    >Subject: Re: Comet implementation in WCF
    >Date: Thu, 20 Nov 2008 09:47:43 +0100


    >
    >> now is some means to check the client connection status when the
    >> server-side finished the method(and ready to return).

    >
    >Yes.
    >
    >> info. And the OperationContext class has a "InstanceContext" property

    that
    >> can help inspect the current communication object's State:

    >
    >Seems to be exactly what I am looking for. I also notice that it has a
    >Closing event that I can hook up to forward the disconnect directly to my
    >service queue. That would mean that I have to store the InstanceContext
    >along the request in my queue object. Is that valid?
    >
    >> BTW, since your server-side WCF operation will take long time to process,
    >> have you used async method call pattern at client-side? I think using
    >> async
    >> approach will make the client-side UI responding perform better.

    >
    >I have used the async pattern on the server, all requests are moved to a
    >separate thread that keeps a queue of the waiting clients. That way I

    won't
    >exhaust the thread pool used to receive the requests, as we are designing
    >for 500+ clients.
    >
    >The client on the other hand is a Windows service whose sole purpose is to
    >wait for the service response, so there might not be a need to use the

    async
    >pattern (depending on how I can process a service stop request).
    >
    >Regards;
    >/jb
    >
    >
     
    Steven Cheng, Nov 21, 2008
    #4
  5. If I understand You correct, this means I need to capture the instance of
    the InstanceContext inside of the BeginXxxx() (where it is available using
    and forward that instance to my queue. This would eliminate the need to use
    the OperationContext method inside my Queue thread (which is a manually
    created thread running outside of the thread pool).

    Regards;
    /jb


    ""Steven Cheng"" <> skrev i meddelandet
    news:...
    > Thanks for your reply Jonny,
    >
    > The "OperationContext" and "InstanceContext" should be available at least
    > during the entire WCF method processing lifecycle. Also, generally if the
    > code is within the same callstack/thread as the WCF's operation method, it
    > can access the Instancecontext via OperationContext. If you switch to
    > other
    > threads(which is not synchronized with the main WCF operation method
    > calling thread), it is not guranteed that you can access the
    > operationContext.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > Delighting our customers is our #1 priority. We welcome your comments and
    > suggestions about how we can improve the support we provide to you. Please
    > feel free to let my manager know what you think of the level of service
    > provided. You can send feedback directly to my manager at:
    > .
    >
    >
    >
    > --------------------
    >>From: "Jonny Bergdahl" <>
    >>References: <#>

    > <>
    >>In-Reply-To: <>
    >>Subject: Re: Comet implementation in WCF
    >>Date: Thu, 20 Nov 2008 09:47:43 +0100

    >
    >>
    >>> now is some means to check the client connection status when the
    >>> server-side finished the method(and ready to return).

    >>
    >>Yes.
    >>
    >>> info. And the OperationContext class has a "InstanceContext" property

    > that
    >>> can help inspect the current communication object's State:

    >>
    >>Seems to be exactly what I am looking for. I also notice that it has a
    >>Closing event that I can hook up to forward the disconnect directly to my
    >>service queue. That would mean that I have to store the InstanceContext
    >>along the request in my queue object. Is that valid?
    >>
    >>> BTW, since your server-side WCF operation will take long time to
    >>> process,
    >>> have you used async method call pattern at client-side? I think using
    >>> async
    >>> approach will make the client-side UI responding perform better.

    >>
    >>I have used the async pattern on the server, all requests are moved to a
    >>separate thread that keeps a queue of the waiting clients. That way I

    > won't
    >>exhaust the thread pool used to receive the requests, as we are designing
    >>for 500+ clients.
    >>
    >>The client on the other hand is a Windows service whose sole purpose is to
    >>wait for the service response, so there might not be a need to use the

    > async
    >>pattern (depending on how I can process a service stop request).
    >>
    >>Regards;
    >>/jb
    >>
    >>

    >
     
    Jonny Bergdahl, Nov 21, 2008
    #5
  6. Jonny Bergdahl

    Steven Cheng Guest

    Thanks for your reply Jonny,

    Yes, since you're using beginXXX to perform async operation, it will result
    to a new background thread-pool thread which may not contain the context
    info as the original one. You'd better use some own variables(accessible in
    the new async thread context) to cache the OperationContext or
    Instancecontext if you want. Also, I think it's better to perform some
    tests to verify that that does work as you expect.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    Delighting our customers is our #1 priority. We welcome your comments and
    suggestions about how we can improve the support we provide to you. Please
    feel free to let my manager know what you think of the level of service
    provided. You can send feedback directly to my manager at:
    .


    --------------------
    >From: "Jonny Bergdahl" <>
    >Subject: Re: Comet implementation in WCF
    >Date: Fri, 21 Nov 2008 09:58:16 +0100


    >
    >If I understand You correct, this means I need to capture the instance of
    >the InstanceContext inside of the BeginXxxx() (where it is available using
    >and forward that instance to my queue. This would eliminate the need to

    use
    >the OperationContext method inside my Queue thread (which is a manually
    >created thread running outside of the thread pool).
    >
    >Regards;
    >/jb
    >
    >
    >""Steven Cheng"" <> skrev i meddelandet
    >news:...
    >> Thanks for your reply Jonny,
    >>
    >> The "OperationContext" and "InstanceContext" should be available at least
    >> during the entire WCF method processing lifecycle. Also, generally if the
    >> code is within the same callstack/thread as the WCF's operation method,

    it
    >> can access the Instancecontext via OperationContext. If you switch to
    >> other
    >> threads(which is not synchronized with the main WCF operation method
    >> calling thread), it is not guranteed that you can access the
    >> operationContext.
    >>
    >> Sincerely,
    >>
    >> Steven Cheng
    >>
    >> Microsoft MSDN Online Support Lead
    >>
    >>
    >> Delighting our customers is our #1 priority. We welcome your comments and
    >> suggestions about how we can improve the support we provide to you.

    Please
    >> feel free to let my manager know what you think of the level of service
    >> provided. You can send feedback directly to my manager at:
    >> .
    >>
    >>
    >>
    >> --------------------
    >>>From: "Jonny Bergdahl" <>
    >>>References: <#>

    >> <>
    >>>In-Reply-To: <>
    >>>Subject: Re: Comet implementation in WCF
    >>>Date: Thu, 20 Nov 2008 09:47:43 +0100

    >>
    >>>
    >>>> now is some means to check the client connection status when the
    >>>> server-side finished the method(and ready to return).
    >>>
    >>>Yes.
    >>>
    >>>> info. And the OperationContext class has a "InstanceContext" property

    >> that
    >>>> can help inspect the current communication object's State:
    >>>
    >>>Seems to be exactly what I am looking for. I also notice that it has a
    >>>Closing event that I can hook up to forward the disconnect directly to my
    >>>service queue. That would mean that I have to store the InstanceContext
    >>>along the request in my queue object. Is that valid?
    >>>
    >>>> BTW, since your server-side WCF operation will take long time to
    >>>> process,
    >>>> have you used async method call pattern at client-side? I think using
    >>>> async
    >>>> approach will make the client-side UI responding perform better.
    >>>
    >>>I have used the async pattern on the server, all requests are moved to a
    >>>separate thread that keeps a queue of the waiting clients. That way I

    >> won't
    >>>exhaust the thread pool used to receive the requests, as we are designing
    >>>for 500+ clients.
    >>>
    >>>The client on the other hand is a Windows service whose sole purpose is

    to
    >>>wait for the service response, so there might not be a need to use the

    >> async
    >>>pattern (depending on how I can process a service stop request).
    >>>
    >>>Regards;
    >>>/jb
    >>>
    >>>

    >>

    >
    >
     
    Steven Cheng, Nov 24, 2008
    #6
  7. Thanks! Will try this.

    Regards;
    /jb

    ""Steven Cheng"" <> skrev i meddelandet
    news:...
    > Thanks for your reply Jonny,
    >
    > Yes, since you're using beginXXX to perform async operation, it will
    > result
    > to a new background thread-pool thread which may not contain the context
    > info as the original one. You'd better use some own variables(accessible
    > in
    > the new async thread context) to cache the OperationContext or
    > Instancecontext if you want. Also, I think it's better to perform some
    > tests to verify that that does work as you expect.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > Delighting our customers is our #1 priority. We welcome your comments and
    > suggestions about how we can improve the support we provide to you. Please
    > feel free to let my manager know what you think of the level of service
    > provided. You can send feedback directly to my manager at:
    > .
    >
    >
    > --------------------
    >>From: "Jonny Bergdahl" <>
    >>Subject: Re: Comet implementation in WCF
    >>Date: Fri, 21 Nov 2008 09:58:16 +0100

    >
    >>
    >>If I understand You correct, this means I need to capture the instance of
    >>the InstanceContext inside of the BeginXxxx() (where it is available using
    >>and forward that instance to my queue. This would eliminate the need to

    > use
    >>the OperationContext method inside my Queue thread (which is a manually
    >>created thread running outside of the thread pool).
    >>
    >>Regards;
    >>/jb
    >>
    >>
    >>""Steven Cheng"" <> skrev i meddelandet
    >>news:...
    >>> Thanks for your reply Jonny,
    >>>
    >>> The "OperationContext" and "InstanceContext" should be available at
    >>> least
    >>> during the entire WCF method processing lifecycle. Also, generally if
    >>> the
    >>> code is within the same callstack/thread as the WCF's operation method,

    > it
    >>> can access the Instancecontext via OperationContext. If you switch to
    >>> other
    >>> threads(which is not synchronized with the main WCF operation method
    >>> calling thread), it is not guranteed that you can access the
    >>> operationContext.
    >>>
    >>> Sincerely,
    >>>
    >>> Steven Cheng
    >>>
    >>> Microsoft MSDN Online Support Lead
    >>>
    >>>
    >>> Delighting our customers is our #1 priority. We welcome your comments
    >>> and
    >>> suggestions about how we can improve the support we provide to you.

    > Please
    >>> feel free to let my manager know what you think of the level of service
    >>> provided. You can send feedback directly to my manager at:
    >>> .
    >>>
    >>>
    >>>
    >>> --------------------
    >>>>From: "Jonny Bergdahl" <>
    >>>>References: <#>
    >>> <>
    >>>>In-Reply-To: <>
    >>>>Subject: Re: Comet implementation in WCF
    >>>>Date: Thu, 20 Nov 2008 09:47:43 +0100
    >>>
    >>>>
    >>>>> now is some means to check the client connection status when the
    >>>>> server-side finished the method(and ready to return).
    >>>>
    >>>>Yes.
    >>>>
    >>>>> info. And the OperationContext class has a "InstanceContext" property
    >>> that
    >>>>> can help inspect the current communication object's State:
    >>>>
    >>>>Seems to be exactly what I am looking for. I also notice that it has a
    >>>>Closing event that I can hook up to forward the disconnect directly to
    >>>>my
    >>>>service queue. That would mean that I have to store the InstanceContext
    >>>>along the request in my queue object. Is that valid?
    >>>>
    >>>>> BTW, since your server-side WCF operation will take long time to
    >>>>> process,
    >>>>> have you used async method call pattern at client-side? I think using
    >>>>> async
    >>>>> approach will make the client-side UI responding perform better.
    >>>>
    >>>>I have used the async pattern on the server, all requests are moved to a
    >>>>separate thread that keeps a queue of the waiting clients. That way I
    >>> won't
    >>>>exhaust the thread pool used to receive the requests, as we are
    >>>>designing
    >>>>for 500+ clients.
    >>>>
    >>>>The client on the other hand is a Windows service whose sole purpose is

    > to
    >>>>wait for the service response, so there might not be a need to use the
    >>> async
    >>>>pattern (depending on how I can process a service stop request).
    >>>>
    >>>>Regards;
    >>>>/jb
    >>>>
    >>>>
    >>>

    >>
    >>

    >
     
    Jonny Bergdahl, Nov 27, 2008
    #7
  8. > So far based on my research, at server-side, WCF method can use
    > "OperationContext.Current" to inspect some WCF method invocation context
    > info. And the OperationContext class has a "InstanceContext" property that
    > can help inspect the current communication object's State:


    Sorry for the late reply, I haven't come around to this until now.

    I am sorry to report that this does not work. The
    OperationContext.Current.InstanceContext.State only seems to track the
    internal state of thre service object, and not the communication state.

    When I have initiated a connection from the client, State is set top Opened.
    But even after I have closed down the Client, it is still set to Opened even
    though the HTTP connection is closed.

    What I need is to keep track of the underlying HTTP connection state,
    something like HttpResponse.IsClientConnected.

    Any other ideas on how to get to the underlying connection?

    Regards;
    /jb
     
    Jonny Bergdahl, Jan 15, 2009
    #8
  9. Jonny Bergdahl

    Steven Cheng Guest

    Hi Jonny,

    I've seen your new thread and posted my reply there. Here is my reply
    content for your convenience:

    <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Hi Jonny,

    Thanks for your followup.

    Also sorry for the late reponse as I was dealing with some other issues
    recently. Regarding on the detecting client-side disconnecting problem,
    I've also performed some further research. It seems for normal one-way
    binding(comparing to thte duplex binding), the client-side disconnect
    detection is not real-time. Here are some web articles discussing on this
    issue:

    #WCF Notification on Disconnect
    http://www.rcs-solutions.com/blog/2008/07/06/WCFNotificationOnDisconnect.asp
    x

    #Taking Action on Client Close
    http://blogs.msdn.com/drnick/archive/2008/01/07/taking-action-on-client-clos
    e.aspx

    #Provide Way to Detect Client Abort/Disconnect in WCF
    http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/7fb25e30-fc74-4a52-
    9dfd-232c67c84f7a

    I've tried registering some eventhandler on the OperationContext's Channel,
    but those event won't be raised until the service method return data to
    client-side. e.g,

    ========================
    public string GetData(string user)
    {
    Console.WriteLine("GetData Begin:{0}", DateTime.Now);


    OperationContext oc = OperationContext.Current;


    oc.Channel.Closed += new EventHandler(Channel_Closed);
    oc.Channel.Closing += new EventHandler(Channel_Closing);
    oc.Channel.Faulted += new EventHandler(Channel_Faulted);


    for (int i = 0; i < 10; ++i)
    {
    Console.WriteLine("Loop:{0}, State:{1}",i,
    oc.Channel.State);


    Thread.Sleep(1000 * 3);
    }


    Console.WriteLine("GetData End:{0}", DateTime.Now);

    return "result of " + user;

    }
    ===============================

    If duplex binding is possible for your scenario, you may have a try on the
    solution mentioned in above articles.
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    Delighting our customers is our #1 priority. We welcome your comments and
    suggestions about how we can improve the support we provide to you. Please
    feel free to let my manager know what you think of the level of service
    provided. You can send feedback directly to my manager at:
    .

    ==================================================
    Get notification to my posts through email? Please refer to
    http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.


    --------------------
    >From: "Jonny Bergdahl" <>
    >Subject: Re: Comet implementation in WCF
    >Date: Thu, 15 Jan 2009 10:55:42 +0100


    >> So far based on my research, at server-side, WCF method can use
    >> "OperationContext.Current" to inspect some WCF method invocation context
    >> info. And the OperationContext class has a "InstanceContext" property

    that
    >> can help inspect the current communication object's State:

    >
    >Sorry for the late reply, I haven't come around to this until now.
    >
    >I am sorry to report that this does not work. The
    >OperationContext.Current.InstanceContext.State only seems to track the
    >internal state of thre service object, and not the communication state.
    >
    >When I have initiated a connection from the client, State is set top

    Opened.
    >But even after I have closed down the Client, it is still set to Opened

    even
    >though the HTTP connection is closed.
    >
    >What I need is to keep track of the underlying HTTP connection state,
    >something like HttpResponse.IsClientConnected.
    >
    >Any other ideas on how to get to the underlying connection?
    >
    >Regards;
    >/jb
    >
    >
     
    Steven Cheng, Jan 21, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mad Scientist Jr

    server pushed events and asp.net? (ie comet)

    Mad Scientist Jr, Oct 15, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    477
    Sahil Malik [MVP C#]
    Oct 15, 2006
  2. tony
    Replies:
    3
    Views:
    526
    Roedy Green
    Jun 29, 2007
  3. Simon
    Replies:
    0
    Views:
    1,026
    Simon
    Oct 13, 2009
  4. Cindy Lee
    Replies:
    1
    Views:
    2,129
    Mr. Arnold
    Mar 19, 2010
  5. Jonny Bergdahl

    Comet implementation

    Jonny Bergdahl, Jan 20, 2009, in forum: ASP .Net Web Services
    Replies:
    4
    Views:
    796
    Steven Cheng
    Feb 2, 2009
Loading...

Share This Page