現在下記の構造体をwinsockで送信しようとしています。szResult[1024*5];}SQLRESULT;サーバーとクライアントを同一PCで立ち上げて、送受信した際は問題なくクライアントで受け取れたのですがLANで繋がれた別PCで実験してみたところ、データが受け取れませんでした。szResult[1024];とバイト数を減らしたところ無事に受信できました同一PCだと受け取れて、LANで繋がれたPCだと受け取れないのはなぜでしょうか??その時に使用していたコードを記します。単純にsendとrecvを行っていただけです。0;}今現在このコードで同一PC内では通信できているのですが、LANでテストできる環境から離れてしまったのでうまくいくか結果は不明です。不安が残るので、添削できる方が居たら、是非お願いいたします。同一PCだと問題なく通信できて、LAN環境に出ると受信できなくなる理由を教えてください。明日戻り値をデバッグしてみます。Cielさんヒントをありがとうございます。##追記ですデバックコードを追加してテストしたとkろお非LAN環境ではクライアント、サーバー側とも同じ数値をrecv,sendしておりました。これをそのままLAN環境で実行してみます。9年前パケットは経路上で分割されるのが普通です。受信は決め打ちではなく分割されてくる前提で組む必要があります。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。非同期化モードのFD_READで受信通知を受けているのですがここにメッセージボックスAPIを噛ませたところ、非LAN環境は一回だけメッセージボックスが出ました。同じコードでLAN環境下ですとメッセージボックスが2回出たのですが。これは二回に分割されてデータが来ているという事でしょうか・・・?そういうことでしょうね。分割数はEthernetフレームのサイズによります。9年前デバックを実行してみました。結果から言うと、前回のままではクライアント側でデータを読み込めませんでした。社内LANが遅延してるのかと思い。以下の様にSleep関数を入れてみた所、クライアント側でうまく受信することが出来ました。0;}Sleepを入れたことで受信できるってことは遅延が考えられるのですが社内LANによるデータ送受信の遅延って起こりうるのでしょうか。環境はプロクシサーバーを通して、外部と接続しているネットワークになります。何かエラーメッセージはなかったのかとか、FD_READは何回飛んできたのかとか、詳しく教えて下さい。読み込めませんでした。以下の様にFD_READ部分のコードを書いているのですが、Sleepを入れないとFD_READメッセージすら呼ばれていない様子でした。cl.rcvData();内のデバックコードが呼ばれなかったです。FD_READ://データ受信通知{cl.rcvData();//データ受信関数を呼び出し。これが前述したコードになります}しかし、cl.rcvDataを呼び出す前に以下のようなコードにすると何故か受信が可能でしたどうやら処理を一時的に止める関数を呼び出すと、データが読み込めるようです。//もしくはスリープ関数を呼び出すcl.rcvData();//データ受信関数を呼び出し。これが前述したコードになります}また、拠点A内の社内LANでテストしたところSleep(50)で全てのデータが読み込み可能だったのですが拠点Aにサーバーを立てて、拠点Bのクライアントで読み込んだところ、Sleep(1000)ほどにしないと読み込めませんでした。両方ともSleep関数やMsgboxなど、処理を一時的に止める関数をかませなければ受信が不可能でした。拠点Aは東京で、拠点Bは大阪になります。ご指導お願いいたします。9年前FD_READすら呼ばれてないのに、FD_READ内にMessageBoxやSleepの処理を書くだけでうまくいくことがあるんですか。9年前cielさん>じゃあやっぱり、FD_READのメッセージは飛んできているのでは?そうですよね。おっしゃる通りなので飛んで来ているのだと思います。>サーバ側のsendではエラーは出てないんですよね?サーバー側のsendサイズも監視していますが、構造体のサイズに対して全て送信出来ていました。さん非同期通信で行っております。nRcv;//受信した分ポインタを進める}アドバイスを頂いたコードで、明日再度テストを実施してみます。皆様ありがとうございます。9年前どちらにしろ、今の設計では、SOCKET_ERRORを返してきた時点で、そのまま処理を終了してしまっていますので、色々と後で問題が出てくるかもしれません。WSAEWOULDBLOCKっていうエラーは大きなデータなどを受信していると、結構頻繁に出るエラーなので、なかなか受信できない状況にならなければいいですけどね。続きから受信するという方法をとりますね。詳しいことは↓のサイトでも見てみてください。最初のステップとして、そんな感じでいいと思います。WinSockの非同期通信やったことがないので確信はありませんが、これでもまだ上手くいかないと思います。これで上手くいかない場合、whileループをなくす、すなわち、1回のFD_READのメッセージで1回のrecv()だけ呼ぶように修正してみてください。9年前>SOCKET_ERRORを返してきた時点でなるほど、、、二回目のFD_READでソケットエラー起こすとデータ切れますね。お二方アドバイスありがとうございます。ご紹介頂いたサイトをみて、今の知識で時間はかかりそうですが、なんとか理解できそうなので少し自分で紐解いて、エラーに対する処理を実装してみたいと思います。頂いたアドバイスを基に、努力してみます。解決マークは付けずにおきます、壁に当たったら再度質問させて下さい。引き続き実験してみました。以下のコードでSleep関数をかまさずに、拠点A内のほかのPCと拠点Bまではデータの送受信が可能でした。拠点Aから600kmほど離れた拠点cではデータの受信が不可能でした。0;}なんだか、WSAEWOULDBLOCKの処理の仕方が怪しいのかなぁ。踏んでいますがお気づきの点はありますでしょうか・・。whileを使わないコードにも挑戦してみようかと思っております。9年前Cielさんがご指摘しているとおり、WSAEWOULDBLOCKが返って来たら、再びFD_READの到着を待ってください。client::rcvData()を抜けてください。1回のrecv()で全てのデータを受信できるとは限らない、ということは認識されているようですが1回のFD_READで全てのデータが届く、と思っていませんか?ソースコード上でwhileループ内で送信したデータ全てを受けようとしていますが、これは間違いです(と、Cielさんも暗に指摘します)。念の為に言っておきますが、ソースコードレベルで、TCP/IP通信の方法に2者の距離は「全く関係ありません」。データ受信が出来ないのは、別に理由が必ずあります。#昨日0Byteリードについて言及しましたが、これは受信バッファが空の場合を考慮に入れるという意味です。#受信バッファが空の時は、WSAEWOULDBLOCKが返って来るみたいなので、昨日の発言は忘れてください。9年前ぽこさんアドバイスありがとう御座います。0;}>念の為に言っておきますが、ソースコードレベルで、TCP/IP通信の方法に2者の距離は「全く関係ありません」。>データ受信が出来ないのは、別に理由が必ずあります。ありがとうございます。returnで処理を抜けたら、次にFD_READが呼ばれるのは何時なのか疑問だったのですが続けざまに通知されるようですね。同一PC間ではうまく動いていますが、明日再度テストを実施してみます。ありがとうございます。9年前ご指摘ありがとうございます。普通のエラーで抜ける場合は初期化しておかないとだめでした。上記のコードで無事に各拠点とも通信することが可能でした。勉強になりました、アドバイス頂いた皆様、ありがとうございました。ミクプラは自由にリンクできます。