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

ASP.NET、C++/CLI、Java 何でもどうぞ

ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

No.92936 の関連記事表示

<< 0 >>
■92936  C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/11(Mon) 11:55:27)

    分類:[C#] 

    初めまして、pandamanといいます。

    タイトルについての質問です。
    初心者ですので、合っているか分からないですが…。

    Windows formsでC#を使用しております。

    内容としまして
    PCで開発したソフト(簡易的なスコアボードのような)を数台のPadにて接続、通信をする際に
    通信方式をバイトストリーム、プロトコルをTCPにて
    送受信処理を行っていますが、時々通信不具合を起こし、上述しましたソフトが動作したりしなかったり…。
    という内容となります。

    そこで、何か通信不具合というものを限りなく0に近づける。
    極論、通信不具合をなくす。というコードやプログラム等をご教示いただければ幸いです。


    宜しくお願い致します。
親記事 /過去ログ161より / 関連記事表示
削除チェック/

■92937  Re[1]: C#にてソフトとPadの通信
□投稿者/ shu -(2019/11/11(Mon) 12:22:44)
    No92936 (pandaman さん) に返信

    > そこで、何か通信不具合というものを限りなく0に近づける。
    > 極論、通信不具合をなくす。というコードやプログラム等をご教示いただければ幸いです。
    >
    通信不具合の原因が何かを調べないと0には近づかないと思います。
    1.物理的にはどうか?
    2.Pad側の処理に何か問題がないか?
    3.再試行すればなんとかなるのか?

    3.がなんとかなれば、少し時間をおいてリトライすればよい気がします。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92942  Re[2]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/11(Mon) 14:53:38)
    No92937 (shu さん) に返信
    > ■No92936 (pandaman さん) に返信
    >
    >>そこで、何か通信不具合というものを限りなく0に近づける。
    >>極論、通信不具合をなくす。というコードやプログラム等をご教示いただければ幸いです。
    >>
    > 通信不具合の原因が何かを調べないと0には近づかないと思います。
    > 1.物理的にはどうか?
    > 2.Pad側の処理に何か問題がないか?
    > 3.再試行すればなんとかなるのか?
    >
    > 3.がなんとかなれば、少し時間をおいてリトライすればよい気がします。

    shuさん返信頂きありがとうございます。
    漠然とした質問にも関わらず回答頂き大変ありがたく思います。

    しかしながら何分初心者なもので、原因が何かという部分すらも分からない状況であります。

    ご指摘の通り、再試行すれば動作する時もありますが、全く動作しない場合もあります。

    はっきり申しますと、前任開発者より引継ぎを行いまして、

    前任者のプログラムを見ながら右往左往している状況でして…。

    こういうプログラム構成だと通信不具合を少なくできるかもしれません。

    というようなアドバイスを頂きたく掲示板に書き込みさせていただいた次第であります。

    漠然とした質問内容ですいませんでした。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92944  Re[3]: C#にてソフトとPadの通信
□投稿者/ 774RR -(2019/11/11(Mon) 15:24:09)
    TCP はエラー訂正や再送を含むプロトコルなので TCP レベルでデータが化けていることは考えにくく
    化けているとしたらあなたの担当することになったそのコードの不具合。

    TCP は「パケット」でなくて「ストリーム」なので send() と receive() が1対1対応しない。
    過去に、1対1対応するはずと誤って考えている例を何度か見ているわけだけど、そうなってない?

    send(100バイト); send(100バイト); を送信側がしていても、受信側は
    - 200バイトを1回で
    - 1バイトを200回で
    - その他任意のバイト数を任意の回数で(合計すると200バイト)
    受け取ることがあって、100バイトを2回とは限らないっす。
    (特に無線通信など媒体が不安定な場合、訂正や再送の結果、サイズはバラバラになりがち)
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92949  Re[4]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/11(Mon) 17:45:09)
    No92944 (774RR さん) に返信
    > TCP はエラー訂正や再送を含むプロトコルなので TCP レベルでデータが化けていることは考えにくく
    > 化けているとしたらあなたの担当することになったそのコードの不具合。
    >
    > TCP は「パケット」でなくて「ストリーム」なので send() と receive() が1対1対応しない。
    > 過去に、1対1対応するはずと誤って考えている例を何度か見ているわけだけど、そうなってない?
    >
    > send(100バイト); send(100バイト); を送信側がしていても、受信側は
    > - 200バイトを1回で
    > - 1バイトを200回で
    > - その他任意のバイト数を任意の回数で(合計すると200バイト)
    > 受け取ることがあって、100バイトを2回とは限らないっす。
    > (特に無線通信など媒体が不安定な場合、訂正や再送の結果、サイズはバラバラになりがち)

    774RRさん 返信頂きありがとうございます。
    とても分かりやすい説明をして頂きました。

    今一度、プログラムを見直してみて
    送信側、受信側の相違がないかなど確認していきたいと思います。

    他にも何かありましたらご教示頂けると大変助かります。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92950  Re[5]: C#にてソフトとPadの通信
□投稿者/ みい -(2019/11/11(Mon) 17:56:41)
    No92949 (pandaman さん) に返信
    > 他にも何かありましたらご教示頂けると大変助かります。
    接続、切断、送信、受信といった通信に関するところで
    ログ書込を行う事をお勧めします。
    送受信バイト数や内容、関数の成功有無など。
    通信が成功する時としない時のログを比較すると
    原因が見えてくるかもしれません。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92954  Re[6]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/11(Mon) 19:13:53)
    No92950 (みい さん) に返信
    > ■No92949 (pandaman さん) に返信
    >>他にも何かありましたらご教示頂けると大変助かります。
    > 接続、切断、送信、受信といった通信に関するところで
    > ログ書込を行う事をお勧めします。
    > 送受信バイト数や内容、関数の成功有無など。
    > 通信が成功する時としない時のログを比較すると
    > 原因が見えてくるかもしれません。
    >

    みいさん 返信頂きありがとうございます。
    実際に試してみたいと思います。
    様々な貴重な意見を頂けて大変助かっております。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92963  Re[7]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 09:28:42)
    おはようございます。
    昨日は様々なアドバイスなどありがとうございました。

    本日は送信の際のプログラムと受信の際のプログラムを載せます。
    774RRさんが言われていたのはこの部分を同じバイトにした方が宜しいという事でしょうか。

    回答頂けるとありがたいです。

    // サーバーへ送信
    byte[] SendBuffer2 = System.Text.Encoding.Unicode.GetBytes(Convert.ToString(SendText));

    // サーバーからの受信
    byte[] ReceiveData2 = new byte[30];

    前任者のプログラムは上記のようなものになっていますが…。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92964  Re[8]: C#にてソフトとPadの通信
□投稿者/ 774RR -(2019/11/12(Tue) 10:26:05)
    そこだけだと、送信してないし、受信してない ...

    > この部分を同じバイトにした方が宜しいという事でしょうか。
    同じバイト *数* ってことなら誤り(っていうか典型的勘違いでオイラの文を逆に読んでる)

    SendBuffer2 に格納された送信電文が 30 バイトで、送る側が 30 バイトを送ったとしても
    受け取る側は
    - 前後の電文にくっついて 1454 バイトを一度に受け取るかもしれないし
    - 分割されて 5 + 9 + 1 + 4 + .. のようにバラバラに受け取るかもしれないし

    ってことで区切る必要がそもそもあるのかないのか、区切るならどう判別するか、を定義するのは
    プログラマの仕事っつか仕様策定者の責任

    TCP は「文字化けはない」ことを保証するけど「区切り位置」は保証しないってこと。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92965  Re[9]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 11:06:55)
    774RRさん
    理解力がなく申し訳ありません。

    //データの送受信処理
    if (!SLTAlive) // まだ接続待ちスレッドを生成していない場合
    {


    // Socket の生成
    ServerSocket = new System.Net.Sockets.Socket(
    System.Net.Sockets.AddressFamily.InterNetwork, // IP version 4 のアドレス
    System.Net.Sockets.SocketType.Stream, // 通信方式をバイトストリーム
    System.Net.Sockets.ProtocolType.Tcp); // プロトコルをTCP

    // ホストのIPアドレスとポート番号の指定
    System.Net.IPEndPoint EndPointHost = new System.Net.IPEndPoint(System.Net.IPAddress.Any, 9100);


    ServerSocket.Bind(EndPointHost); // ローカル エンドポイント(IPアドレス等の情報)と関連付け
    ServerSocket.Listen(500); // 電文取り出しの接続がまだ保留中におけるキューの最大長

    // 接続待ち用スレッドを作成
    ListeningCallbackThread = new System.Threading.Thread(ListeningCallback);
    // 接続待ち用スレッドを開始
    ListeningCallbackThread.Start();
    // スレッド終了指示フラグを未終了に設定
    SLTAlive = true;
    }

        //********************************************************************
    //データの送信(ソケット通信)
    //SendTextData関数(第1引数:送信相手IPアドレス、第2引数:送信データ)
    //********************************************************************
    private void SendTextData(String receiver, String SendText)
    {
    try
    {
    System.Net.Sockets.TcpClient client1 = new System.Net.Sockets.TcpClient(); // TCPクライアントを生成
    // TCP/IP接続を行う(メインサーバーのIPアドレス指定(メインサーバー内))
    if (!client1.ConnectAsync(receiver, 9100).Wait(300))
    {

    }

    // 通信ストリームの取得
    System.Net.Sockets.NetworkStream stream2 = client1.GetStream();

    // サーバーへ送信
    byte[] SendBuffer2 = System.Text.Encoding.Unicode.GetBytes(Convert.ToString(SendText));

    stream2.Write(SendBuffer2, 0, SendBuffer2.Length);

    stream2.Flush(); // フラッシュ(強制書き出し)

    // サーバーからの受信
    byte[] ReceiveData2 = new byte[30];

    stream2.Read(ReceiveData2, 0, ReceiveData2.Length);

    string str2 = System.Text.Encoding.Unicode.GetString(ReceiveData2);

    // TCPクライアントをクローズ
    client1.Close();

    }
    catch
    {

    }
    }

    この辺りの定義?でおかしいところがあったりしますでしょうか。
    プログラム自体、全くの未経験者ですいません・・・。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92967  Re[10]: C#にてソフトとPadの通信
□投稿者/ 774RR -(2019/11/12(Tue) 11:19:38)
    うーん、どうしよう、いろいろおかしい。 TCP である前提で

    stream2.Flush(); はほとんど意味がない(理由は既述)があっても無害
    stream2.Read() の結果を捨ててるのは論外(理由は既述)
    client1.Close() を毎回してるとポート枯渇にならないかな? (TIME_WAIT)

    少なくとも Read() で必要バイト数を受け取れたかどうかはチェックしないと ...
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92975  Re[11]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 13:29:50)
    No92967 (774RR さん) に返信
    > うーん、どうしよう、いろいろおかしい。 TCP である前提で
    >
    > stream2.Flush(); はほとんど意味がない(理由は既述)があっても無害
    > stream2.Read() の結果を捨ててるのは論外(理由は既述)
    > client1.Close() を毎回してるとポート枯渇にならないかな? (TIME_WAIT)
    >
    > 少なくとも Read() で必要バイト数を受け取れたかどうかはチェックしないと ...

    774RRさん ありがとうございます。
    そもそものプログラムがしっかりと確立されていないからエラーが通信不具合を発生している。
    ということですよね。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92978  Re[12]: C#にてソフトとPadの通信
□投稿者/ Hongliang -(2019/11/12(Tue) 13:47:18)
    catch { }
    の中は実際にはログを出したりなんやかんやしてるんですよね?
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92991  Re[13]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 16:19:21)
    No92978 (Hongliang さん) に返信
    > catch { }
    > の中は実際にはログを出したりなんやかんやしてるんですよね?

    Hongliangさん
    catchの中は空です。特に何もありません。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92981  Re[10]: C#にてソフトとPadの通信
□投稿者/ みい -(2019/11/12(Tue) 14:14:17)
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92992  Re[11]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 16:28:43)
    pingを使用した通信とTCPを使用した通信だとどちらが良いとかありますか?
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92993  Re[12]: C#にてソフトとPadの通信
□投稿者/ 774RR -(2019/11/12(Tue) 16:50:46)
    ping (ICMP) だと任意の電文を送るわけにはいかないし、到達性のチェックにしか使えないよ?
    ネットワークケーブルが外れているとか相手機器が電源切れてるとか.

    TCP は任意電文が確実に届く保証がある(到達時間は保証されない)から、
    普通の意味でのデータ転送には TCP を使うのが一番手っ取り早くて確実

    例外握り潰し君か・・・デバッグするなってことだね!
    なんかネット掲示板であれこれ相談してもどうにもならない感がしてきたっす。
    リアルで面倒見てくれそうなネットワークに詳しい人はいないのかな。
    こういう場でチマチマ質疑応答しても埒があかない気が・・・
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■92994  Re[13]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/12(Tue) 17:19:36)
    No92993 (774RR さん) に返信
    > ping (ICMP) だと任意の電文を送るわけにはいかないし、到達性のチェックにしか使えないよ?
    > ネットワークケーブルが外れているとか相手機器が電源切れてるとか.
    >
    > TCP は任意電文が確実に届く保証がある(到達時間は保証されない)から、
    > 普通の意味でのデータ転送には TCP を使うのが一番手っ取り早くて確実
    >
    > 例外握り潰し君か・・・デバッグするなってことだね!
    > なんかネット掲示板であれこれ相談してもどうにもならない感がしてきたっす。
    > リアルで面倒見てくれそうなネットワークに詳しい人はいないのかな。
    > こういう場でチマチマ質疑応答しても埒があかない気が・・・
    >

    774RRさん
    本当の初心者ですいません。全く何も分からないので…。
    原因を探してみます。ありがとうございました。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■93001  Re[14]: C#にてソフトとPadの通信
□投稿者/ みい -(2019/11/13(Wed) 10:31:50)
    catchで例外の内容を見て・・・といってもどこで発生したものか
    理解できないでしょうから、まずはtry/catchをコメントにして
    例外を殺さないようにしてください。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/

■93002  Re[15]: C#にてソフトとPadの通信
□投稿者/ pandaman -(2019/11/13(Wed) 11:32:58)
    No93001 (みい さん) に返信
    > catchで例外の内容を見て・・・といってもどこで発生したものか
    > 理解できないでしょうから、まずはtry/catchをコメントにして
    > 例外を殺さないようにしてください。
    >
    みいさん 返信頂きありがとうございます。
    色々と勉強します。
記事No.92936 のレス /過去ログ161より / 関連記事表示
削除チェック/



<< 0 >>

パスワード/

- Child Tree -