16

「ステータス ツール」を伴う Windows サービスを作成しています。このサービスは、プロセス間通信用の WCF 名前付きパイプ エンドポイントをホストします。名前付きパイプを介して、ステータス ツールは定期的にサービスに最新の「ステータス」を問い合わせることができます。

ここに画像の説明を入力

私の開発マシンには複数の IP アドレスがあります。そのうちの 1 つは、192.168.1.XX アドレスを持つ「ローカル」ネットワークです。もう 1 つは「企業」ネットワークで、アドレスは 10.0.X.XX です。Windows サービスは、単一の IP アドレスで UDP マルチキャスト トラフィックを収集します。

Windows サービスは、「192.168.1.XX」アドレスを使用している限り、これまで正常に機能していました。クライアントに常に正しくステータスを報告します。

他の「企業」IPアドレス(10.0.X.XX)に切り替えてサービスを再起動するとすぐに、ステータスを取得するときに「CommunicationExceptions」が連続して発生します。

"There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)."

ここで、UDP クライアントの「要求された」IP アドレスが Named-Pipe インターフェースの機能と関係があるとは思いません。それらはアプリケーションの完全に別の部分です。

関連する WCF 構成セクションは次のとおりです。

//On the Client app:
string myNamedPipe = "net.pipe://127.0.0.1/MyNamedPipe";
ChannelFactory<IMyService> proxyFactory =
    new ChannelFactory<IMyService>(
        new NetNamedPipeBinding(),
        new EndpointAddress(myNamedPipe));


//On the Windows Service:
string myNamedPipe = "net.pipe://127.0.0.1/MyNamedPipe";
myService = new MyService(myCustomArgs);
serviceContractHost = new ServiceHost(myService );
serviceContractHost.AddServiceEndpoint(
    typeof(IMyService),
    new NetNamedPipeBinding(),
    myNamedPipe);

serviceContractHost.Open();

これは「権限」の問題ではないと思います - 私は管理者権限でクライアントを実行しています - しかし、おそらくこれが壊れたドメイン固有の理由がありますか?

4

10 に答える 10

3

同じ問題がありましたThere was an error reading from the pipe: Unrecognized error 109 (0x6d).

  • 理由の 1 つは、クライアントとサーバー間のバインドの一貫性<netNamedPipeBinding> <security mode="None"></security>...がない(通信がない)ことでした。
  • もう 1 つの断続的な問題は、タイムアウトに関連していました。

両方とも同じトップ エラー メッセージが表示されました。

サーバーとクライアントのバインドでタイムアウトを増やすと、問題が再発しなくなりました。

設定が低すぎるバインド タイムアウト:

sendTimeout="00:00:05" receiveTimeout="00:00:05"

スタックトレース: at System.ServiceModel.Channels.StreamConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) at System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan timeout) at System.ServiceModel.Channels.SynchronizedMessageSource.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceive(TimeSpan timeout, Message& message) at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

于 2014-11-14T10:23:13.010 に答える
2

これは、返されたペイロードが大きすぎるときに、私の WCF サービスで発生しました。これを app.config の serviceBehavior に追加して修正しました:

<dataContractSerializer maxItemsInObjectGraph="[some big number]" />
于 2015-06-25T16:35:16.413 に答える
1

サービス操作がスローされ、チャネルに実際に障害が発生したときに、このエラーが発生しました。あなたの場合、サービス操作自体が正しく完了し、リターンのみがスローされたことを既に確認していますが、疑問がある場合は、サービス操作が正常に実行されることを確認してください。

于 2013-07-08T09:00:34.190 に答える
1

set{ } のないプロパティがたくさんありました。これを追加すると、私の問題が解決しました。

于 2016-06-07T08:19:56.190 に答える