問題タブ [winsock]

ネットワーク経由でデータを送信する必要があるアプリケーションを作成しています。申請は完了しましたが、データの送信に問題があります。データを送るたびに4文字で途切れて残りがゴミ。このアプリケーションは、私が学校のプロジェクト用に書いているリモート キーロガーであり、フックと winsock の使用方法を示す必要があります。フォーラムで助けを求めることができます。どんな助けでも大歓迎です！

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

サーバ：

クライアント：

私はいくつかのコードを BSD ソケットから Winsock に移植していますが、以下のケースの処理方法がわかりません。

私の元のアプリケーションは、stdin とネットワーク ソケットの両方で選択を実行します。

これを Winsock で実行しようとすると、エラー 10038 (WSAENOTSOCK) が発生します。Linux ではファイル ハンドル 0 (stdin) であったものは、Windows ではソケット (より正確には SOCKET タイプ) ではないため、これは理にかなっています。

このテストを Windows ソケットに移植する簡単な方法はありますか?

http://tangentsoft.net/wskfaq/examples/basics/select-server.htmlにあるこの実装例を使用しています

これは私が必要とすることのほとんどを行っており、ブロックせずに接続を処理し、そのスレッドですべての作業を行います (いくつかの例のように接続ごとに新しいスレッドを作成するのではありません)。最大 64 クライアント接続:S

この 64 接続は本当ですか?

他にどのような選択肢がありますか? 同様の実装の C++ の例があると便利です。

ありがとう

それが助けになるなら、C＃のWebRequestにも同様のクラスがあります。Javaや.NETでは必要ありませんが、ネイティブC / C ++コード（Windows用）でこれを実装する方法を考えています。

参考のために：

プリントアウト：

「OK」の意味

おそらくソケットを使用してUser-Agent文字列を送信する必要があることは理解していますが、どこから始めればよいのかわかりません。私が新しい言語を学ぶときはいつでも、私が最初にしたいのは私のコードをそれに移植しようとすることです、しかしこれは私を困惑させました。

どんな助けでも大歓迎です

TCP トランスポート スタックの根底にあるのは、作成者によって時々文書化されている多数のバッファ制限です。WinXP SP3 で、これらのいずれかに遭遇したと思いますが、その理由がわかりません。

サーバーからデータを取得するための単純なクライアントを実装しました (同僚が Java で作成しました)。プロトコルは、データの長さ (ネットワーク順) を 4 バイトで書き込み、次にデータを書き込みます。サーバーは、データを 1024 バイト ブロックで TCP ストリームに書き込みます。クライアントはデータ バッファーの長さを正しく受け取り、メモリを割り当て、ループ内で recv を繰り返し呼び出して、すべてのデータを取得します。

TCP_BlockSize を 4095 以下に設定すると、すべて問題なく、数メガバイトの転送を受信できます。4096 サイズの受信ブロックを試すと、残りのデータに対する最後の要求 (len - currentLen < TCP_BlockSize) は常に失敗し、戻り値 -1 と errno = 0 になります。データが送信され、815054 ～ 834246 バイトの間のどこかですべてが 4096 バイトの受信ブロックでブームになります。

もう 1 つの詳細: サーバーは、最後のバイトを送信した後にソケットを閉じます。なぜ残りのデータが返されないのでしょうか? ストリームが空ではなく閉じられていないときに recv から -1 を受け取るのは曖昧なので、ストリームが空で閉じられるまで recv から -1 を返さないのは欠陥のように感じます。

では、最後のデータを取得するにはどうすればよいでしょうか。

私は winsock を使用しておりconnect、ノンブロッキング ソケットを呼び出しています。CPU が他のプロセスによって占有されている場合、関数が戻る前に遅延 (最大 200 ミリ秒) が発生することがあります。私が知っていることから、connectノンブロッキングソケットの a はすぐに返されるはずですが、おそらくconnectコンテキストスイッチが発生し、CPU が一生懸命働いているため、スレッドが再び CPU 時間を取得して関数を終了するまでに時間がかかります。

ブロッキングソケットではコンテキストスイッチが発生することを知っています（または少なくともかなり確実です）が、非ブロッキングソケットでconnectはコンテキストスイッチが発生しますか？connect

私はリモーティングにかなりの経験がありません。私はそれを使用しようとしていますが、TcpChannel を開くときに WinSock エラー 10048 を受け取り続けています。

MSDN の最も単純なコードを使用します。

初めて実行したときは正常に動作して終了しましたが、2 回目以降はソケット 9090 が既に使用されているなどのエラー 10048 が表示され続けます。Netstat -a ポート 9090 は、すでに閉じられているため、まったく表示されません。

私は何を間違っていますか？

それなし：

• MFC
• ATL

純粋な C++ を使用すると、WSAGetLastError()は10014を返します- 不正なアドレス

• 私が見逃している/間違っていることは何ですか?

コード図:

getaddrinfo()ホスト名を IP アドレスに変換しないconnect()ため、サーバーには変換されません。実装に何か問題がありますか?警告メッセージなしでコンパイルされますか?

この関数呼び出しはconnect正しいですか?

以下にリストされている完全な実装：

私のコードが作成しなかったハンドルがGetFileType()==FILE_TYPE_PIPEソケットであるかどうかを判断する必要があります。このための API はないようです。

私は以下を試しました。一般的な考え方は、ソケット固有の関数を使用し、失敗を非ソケットを意味するものとして扱うことです。

• getsockopt()-- 初めての試みでした。残念ながら、同じ (非ソケット) ハンドルで多くのスレッドから呼び出されるとハングするようです。
• WSAEnumNetworkEvents()-- これは Gnulib が行うことですが、ハンドルがソケットの場合、望ましくない副作用があります。
• getpeername()-- これは cygwin が行うことですが、一部のソケットでも失敗します。エラーがソケット性を意味するかどうかを推測することは、信頼できず、将来的に安全ではないようです。

ソリューションが Windows の一部のバージョン (Vista など) でのみ機能するかどうかは気にしません。一般的なケースでは、いつでも他の方法にフォールバックできます。