接続切断後にWCFの信頼できるメッセージングでサーバーから応答を受け取る方法

Question

クライアント/サーバーWCFを作成しました。私が望むのは、このクライアントからサーバーにメッセージを送信し、何らかの理由で接続が切断された場合です。例えば、クライアントがシャットダウンすると、このクライアントは再び利用可能になったときにどのように応答することができますか？

クライアントとサーバーの間にセッションなどを設定することはできますか？

私のクライアントコードは次のとおりです。

private static void Main(string[] args) 
{ 
    var client = new FlipCaseServiceClient("ReliableMessageService"); 
    var sd = new StringData { FirstName = "Turgut", LastName = "Kançeltik" }; 

    var fullName = client.GetFullName(ref sd); 

    Console.WriteLine(fullName); 
} 

マイServerのコードは次のとおりです。

要約で

[DeliveryRequirements(RequireOrderedDelivery = true)] 
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Single)] 
public class FlipCaseService : IFlipCaseService 
{ 
    public string GetFullName(ref StringData stringData) 
    { 
     var fullName = $"{stringData.FirstName} {stringData.LastName}"; 

     stringData.FullName = fullName; 
     return fullName; 
    } 
} 

とサーバーの構成：ここ

<service behaviorConfiguration="ServiceBehaviorMetaData" name="FlipCaseService.FlipCaseService" > 
    <endpoint name="ReliableMessageService" address="flipcase/wsAddress" binding="wsHttpBinding" bindingConfiguration="BindingReliableMessaging" contract="FlipCaseService.IFlipCaseService" > 
    <identity> 
     <dns value="localhost" /> 
    </identity> 
    </endpoint> 
</service> 

<bindings> 
    <wsHttpBinding> 
    <binding name="BindingReliableMessaging"> 
     <reliableSession enabled="true" inactivityTimeout="00:10:00"/> 
    </binding> 
    </wsHttpBinding>  
</bindings> 

<behavior name="ServiceBehaviorMetaData"> 
    <serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost:8080/flipcase/metadata" /> 
    <serviceDebug includeExceptionDetailInFaults="true" /> 
</behavior> 

Answer 1

一つの合理的なアプローチは、非同期要求を使用することです-応答。つまり、クライアントはサーバーが作業を完了するのを待たずに、要求と忘れを起動します。サーバーが終了すると、クライアントは操作の結果を呼び出します。具体的には、WCFはそれを達成するための二重契約を持っています：http://www.codeproject.com/Articles/491844/A-Beginners-Guide-to-Duplex-WCF。

サーバーの応答が準備ができたら、クライアントに配信しようとします。それが失敗すると、サーバーは、成功またはタイムアウトに達するまで、後で再試行できます。

このパターンに従うと、クライアントには一意の識別子が必要です。接続が復元されても、サーバーは同じクライアントであると認識し、このクライアントが待っている応答を認識します。

もう1つのアプローチは、ある（限られた）時間の間、結果をサーバーにキャッシュすることです。リクエストごとに一意のIDを指定し、そのIDのリクエストがすでに完了しているかどうかサーバーで確認し、そうであれば結果を即時に配信します。それ以外の場合は、応答を処理し、限られた時間キャッシュします。クライアントが少し後で再試行します。クライアントでは、失敗したら再試行してください。