C# と VB.NET の質問掲示板

■No46648 (やじゅ さん) に返信

やじゅさん、返信ありがとうございます。

> Debug Diagnostic Tool を使ってみるとか
> 下記サイトはIISの例ですが、通常のプロセスでも使えます。
> http://keicode.com/iis/iis503.php

コレは凄いですね！(無知ですみません…)
試験環境にはインストールできませんが、開発機で監視させようと思います。
いつもありがとうございます。


■No46651 (なちゃ さん) に返信

なちゃさん、返信ありがとうございます。

> 一応念のためですが、BeginReceiveに対応するEndReceiveは呼んでますよね？

受信部分のもう少し詳細なコードを以下に示します。

　　'''UIクラス側で呼ばれるメソッド
　　'''ソケットオブジェクト1つにつき、一度しか呼ばれません
　　Public Sub ReceiveStart() 
        
        ※処理省略
        ※ソケット接続確認、非同期受信の開始確認をしています

        ' '受信バッファを初期化する
        Dim receiveBuffer(Me._maxReceiveLength) As Byte
        Me._receivedBytes = New System.IO.MemoryStream

        ' '非同期受信を開始
        Try
            Me._socket.BeginReceive(receiveBuffer, 0, receiveBuffer.Length, _
                                    Sockets.SocketFlags.None, _
                                    New AsyncCallback(AddressOf ReceiveCallBack), receiveBuffer)
        Catch
            'ソケットが閉じたとき
            Me.Close()
            Return
        End Try
　　End Sub


　　'''コールバックメソッド
　　'''AsyncCallbackデリゲートによって呼び出されるメソッドです
　　Public Overridable Sub ReceiveCallBack(ByVal ar As System.IAsyncResult) 
        ' '受信データ長
        Dim rlen As Integer = -1
        Dim err As System.Net.Sockets.SocketError = Nothing
        Try
            SyncLock Me.syncSocket
                ' '読み込んだ長さを取得
                rlen = Me._socket.EndReceive(ar, err)
            End SyncLock
        Catch
            'Socketを閉じた時
        End Try

 		' '切断されたか調べる
        If rlen <= 0 Then
            ' ''切断している場合、ソケットを閉じる
            Me.Close()
            Return
        End If

        ' '受信したデータを蓄積する
        Me._receivedBytes.Write(CType(ar.AsyncState, Byte()), 0, rlen)

		※処理省略
		※イベントライズさせ、UI画面に通知します。
		
	  	' '受信バッファサイズ再設定
        ReDim receiveBuffer(Me._maxReceiveLength)

        SyncLock Me.syncSocket
            ' 'ソケット切断チェック
            If _socket Is Nothing Then
                ' ''切断している場合は非同期受信終了
                Return
            End If
            Try
                ' '非同期受信再開
                Me._socket.BeginReceive(receiveBuffer, 0, receiveBuffer.Length, _
                    Sockets.SocketFlags.None, _
                    New AsyncCallback(AddressOf ReceiveCallBack), receiveBuffer)　←●稀に無反応に…
            Catch
                'ソケットが閉じたとき
                Me.Close()
                Return
            End Try
        End SyncLock
    End Sub


なお、このソースコードは
http://codezine.jp/article/detail/22?p=1
を参考に組んである事を記しておきます。
(どぼん！さん、いつもお世話になっております。)

そこで、いつも止まるのが●印の場所です。
現象は先にも述べた通り、スレッドプールにスレッドが新しく生成されない状態のまま
永遠に止まります。
また、System.Windows.Forms.Timerもスレッドプールを使用しているためか、
この後、イベントを通知してもらえません。
メインスレッド自体は動作するようです。

そういえばインストールしてある環境を申告し忘れていました。
・.NET Framework 3.5 (SP1ではありません)
・MS Office 2007
がインストールされています。
これは今回の事象に影響するのでしょうか？

蛇足ですが…
リソースモニタとにらめっこしていたら気になる数値がありました。
メモリの「ハードフォールト(ページフォールト)/分」が単体で常時900程度です。
これは問題ないのでしょうか？
(明らかにパフォーマンスに影響しているとは思いますが…)


追伸：れいさんへ
BeginSendに変えてみましたが、変わりなかった事を報告します。
また、ThreadPool.GetAvailableThreadsを出力するためには
実行スレッドが関係ありますでしょうか？
常時、ワーカースレッド数：500、非同期I/Oスレッド数：999
となります。

皆様、いつもありがとうございます。

以上、よろしくお願い致します。

■No46671 (れい さん) に返信

返信ありがとうございます。
こちらの返信が遅れてしまい、申し訳ございません。
早速、インラインにて返答、質問します。

>>BeginSendに変えてみましたが、変わりなかった事を報告します。
>>また、ThreadPool.GetAvailableThreadsを出力するためには
>>実行スレッドが関係ありますでしょうか？
> 
> 関係ありません。
> 常時一定値ならばそこに問題はありませんね。

了解しました。
今回の問題はスレッドプールの実行スレッド数には関係なさそうですね。


>>受信部分のもう少し詳細なコードを以下に示します。
> 
> ちょうどいま同じようなコードでごにょごにょしています。
> 長期間実行していませんが、今のところBeginReceiveでは止まりません。
> 何がちがうのでしょう？
> 
> 気になる点を挙げてみます。
> 
> 
>>　　'''コールバックメソッド
>>　　'''AsyncCallbackデリゲートによって呼び出されるメソッドです
>>　　Public Overridable Sub ReceiveCallBack(ByVal ar As System.IAsyncResult) 
>>        ' '受信データ長
>>        Dim rlen As Integer = -1
>>        Dim err As System.Net.Sockets.SocketError = Nothing
>>        Try
>>            SyncLock Me.syncSocket
>>                ' '読み込んだ長さを取得
>>                rlen = Me._socket.EndReceive(ar, err)
>>            End SyncLock
>>        Catch
>>            'Socketを閉じた時
>>        End Try
> 
> 
> このCatchでの例外処理はどうなっていますか？
> 握りつぶしてしまっているなら、次のBeginReceiveがおかしくても不思議ではありません。

記載通り、しっかりと握りつぶしてました…。
クローズ処理とリターン処理を追加してみようと思います。
と、ここでのエラーもログに出力するようにしてみます。


>>		※処理省略
>>		※イベントライズさせ、UI画面に通知します。
> 
> UIオブジェクトの操作はきちんとUIスレッドから行っていますか？

こちらはきちんとUIオブジェクトからInvokeさせていました。
一応、InvokeRequiredで判断してます。


>>	  	' '受信バッファサイズ再設定
>>        ReDim receiveBuffer(Me._maxReceiveLength)
> 
> receiveBufferはスコープ外のはずです。
> どこでどう定義され、どう操作していますか？
> きちんとアクセスしていますか？
> 
> もしreceiveBufferが該当クラスのメンバなら、
> _socketをSyncLockで囲うのと同様、receiveBufferも囲うべきでしょう。

receiveBufferはオート(ローカル)変数です。
ReceiveCallBackメソッドの内部で定義されています。

ここで1つ質問なのですが、
Socket.BeginReceive メソッド (Byte[] _
                             , Int32 _
                             , Int32 _
                             , SocketFlags _
                             , SocketError _
                             , AsyncCallback _
                             , Object)
の第一引数である Byte[] はオート変数でも問題ないのでしょうか？
(私は、引数がByval形式である以上、コピーが渡されると考えています。
…が、厳密にはInteger型等限られた型のみしか値渡ししないのでしょうか？)


>>        SyncLock Me.syncSocket
>>            ' 'ソケット切断チェック
>>            If _socket Is Nothing Then
>>                ' ''切断している場合は非同期受信終了
>>                Return
>>            End If
>>            Try
>>                ' '非同期受信再開
>>                Me._socket.BeginReceive(receiveBuffer, 0, receiveBuffer.Length, _
>>                    Sockets.SocketFlags.None, _
>>                    New AsyncCallback(AddressOf ReceiveCallBack), receiveBuffer)　←●稀に無反応に…
>>            Catch
>>                'ソケットが閉じたとき
>>                Me.Close()
>>                Return
> 
> BeginReceiveが同期的に終了する可能性があることを考慮していますか？
> BeginReceiveの実装がどうなっているのかは知りませんが、
> 一般の非同期呼び出しは同期的な終了もあり得ます。

私の不勉強で理解できませんでした…。

まず、この点ですが、この「可能性」が発生する要因が判りません。
スレッドプールの制限や、ソケットオブジェクトの破棄の他に有り得るということですよね？
(OSやサービスの暴走、ハード的な問題はさておき…)
一般的な非同期呼び出しはデリゲートやスレッドプールを利用した実行から、
スレッド生成までということですよね？
何故、「同期的な終了」が発生するのでしょうか？

> その場合ReceiveCallBackが再帰的に呼ばれることになりますので、
> BeginReceive以降のコードやこのインスタンスのほかのメンバの操作で気を使わなければいけません。
同期的終了によって再帰的に呼ばれる…？？
その場合の実行スレッドはどうなっているのですか？
ちょっと頭が混乱してきました。

ReceiveCallBackを実行するスレッドはAsyncCallbackによるデリゲートを利用した
非同期スレッド…じゃないんでしょうか？
すみません、非同期やソケットクラスを分かったつもりでいたようです…。

質問ばかりですみません。
ですが、せっかく教えて頂いたので、最後まで理解したい思いがあります。

何卒ご教授願います。

>>蛇足ですが…
>>リソースモニタとにらめっこしていたら気になる数値がありました。
>>メモリの「ハードフォールト(ページフォールト)/分」が単体で常時900程度です。
>>これは問題ないのでしょうか？
>>(明らかにパフォーマンスに影響しているとは思いますが…)
> 
> これだけではなんとも。
> BeginReceiveが止まることと因果関係があるかもしれませんが、
> そこからBeginReceiveを正常に動作させるための知見は得られないでしょう。

蛇足まで返信ありがとうございます。
とりあえず、本件と話が逸れますので、
この蛇足はここで終わりにします。

以上、よろしくお願い致します。