Windows ソケット : バイトの順序付け

[アーティクル]
02/21/2013

この技術情報、および 2 個の関連レポートは、 Windows ソケットプログラミングのいくつかの問題について説明します。この技術情報ではバイト数命令について説明します。そのほかの問題は技術情報でカバーされています: Windows ソケット: ブロックと Windows ソケット: 文字列の変換。

クラス CAsyncSocketを使用または取得する場合は、これらの懸案事項を管理する必要があります。クラス CSocketを使用または取得する場合、 MFC は自動的にこれらを管理します。

処理命令

異なるバイト順を使用して異なるコンピューターアーキテクチャ、ストアのデータ。たとえば、（Macintosh Motorola）のマシンの逆順の Intel ベースのコンピューターストアのデータ。「小さい Endian いう Intel のバイト順は、ネットワーク」標準「ビッグエンディアンの」を逆の順序です。次の表は、これらの用語を示しています。

大きいと小さいサイズ Endian 命令

処理命令	説明
ビッグエンディアン。	最上位バイトは、 Word の左端です。
小さいEndian	最上位バイトは、 Word の右端にあります。

通常、ネットワークに、ありますが、バイト順を変換する必要がある状況が送信し、が受け取るデータのバイト順の変換を気にする必要はありません。

バイト順を変換する必要があります。

バイト順を次の場合に変換する必要があります:

、別のコンピューターに送信するデータに対してネットワークに解釈する必要のある情報を渡しています。たとえば、理解するネットワークのアドレス渡す必要がある場合があります。とポートを示します。
、通信しているサーバーアプリケーションは、 MFC アプリケーションではありません（および、そのためのソース・コードを行わないようにしてください）。2 台のコンピューターが同じバイト命令を共有するこのバイト順の変換の呼び出し。

バイト順を変換する必要がない場合

バイト順を次の場合に変換することの作業を回避できます:

両端のコンピューターがバイトを入れ替えないことに合意しマシンが同じバイト順を使用します。
対象と伝達いるサーバーは、 MFC アプリケーションです。
対象と伝達ため、バイト順を変換する必要があるかどうかを明示的に判断できます。サーバーのソース・コードがあります。
MFC にサーバーを移植できます。これはするが比較的簡単です。またその結果、より小さく、より高速なコードです。

CAsyncSocketを使用して、自分で必要なバイト順の変換を管理します。Windows ソケットは、「」ビッグエンディアンのバイト順のモデルを標準化し、この順序他の変換に関数を提供します。ただし、 CSocketで使用するCArchiveは、カウンター（「小さい Endian」）順序、 CArchive を処理し、のバイト順の変換の詳細使用します。アプリケーションでこの標準命令または Windows ソケットのバイト順の変換関数を使用することを使用して、コードを移植にできます。

MFC ソケットを使用するための適切な場合は通信の両端を記述しているときです: 両端に MFC を使用します。書き込む非 MFC アプリケーションと、 FTP サーバーなど、通信するアプリケーションは、 Windows ソケット変換ルーチン ntohs、 ntohl、 htonsと htonlを使用してアーカイブオブジェクトにデータを渡す前に、自身をバイト交換を管理する必要があります。非 MFC アプリケーションとの通信に使用されるこの技術情報でこれらの関数の例では、に表示されます。

[!メモ]

通信のもう一方の端が MFC アプリケーションの場合、レシーバーがそれらを扱えないため、アーカイブに CObject から派生する C++ オブジェクトをストリーミングを避けます。Windows ソケット: アーカイブを持つソケットを使用するのメモを参照してください。

バイト順に関する詳細については、 Windows SDKで使用できる Windows ソケットの仕様を参照してください。

バイト順の変換の例

次の例は、アーカイブを使用する CSocket のオブジェクトのシリアル化関数を示します。また、 Windows ソケット API のバイト順の変換関数を使用する方法について説明します。

この例には、後にソース・コードにアクセスできない非 MFC のサーバーアプリケーションと通信するクライアントを記述する例を示します。このシナリオでは、非 MFC サーバーがネットワーク標準のバイト順を使用すると仮定します。これに対し、 MFC のクライアントアプリケーションは CSocket のオブジェクトのある CArchive のオブジェクト、および CArchive の使用「小さい Endian」バイト順、ネットワーク標準のオブジェクトを使用します。

、通信する予定の非 MFC サーバーとします。次のようなメッセージパケットに対して設定されるプロトコルを使用する:

struct Message
{
   long MagicNumber;
   unsigned short Command;
   short Param1;
   long Param2;
};

MFC の用語では、これは次のように表現されています:

struct Message
{
    long m_lMagicNumber;
    short m_nCommand;
    short m_nParam1;
    long m_lParam2;

    void Serialize( CArchive& ar );
};

C++ では、 struct は、クラスと基本的に同じです。Message の構造は上で宣言された Serialize のメンバー関数などのメンバー関数を持つことができます。Serialize のメンバー関数は、次のような可能性があります:

void Message::Serialize(CArchive& ar)
{
    if (ar.IsStoring())
    {
        ar << (DWORD)htonl(m_lMagicNumber);
        ar << (WORD)htons(m_nCommand);
        ar << (WORD)htons(m_nParam1);
        ar << (DWORD)htonl(m_lParam2);
    }
    else
    {
        WORD w;
        DWORD dw;
        ar >> dw;
        m_lMagicNumber = ntohl((long)dw);
        ar >> w ;
        m_nCommand = ntohs((short)w);
        ar >> w;
        m_nParam1 = ntohs((short)w);
        ar >> dw;
        m_lParam2 = ntohl((long)dw);
    }
}

1 種類の末尾の非 MFC のサーバーアプリケーションのバイト命令ともう一方の端の MFC クライアントアプリケーションで使用される CArchive 間に明確に矛盾があるため、データのバイト順の変換の例の呼び出し。例では、バイト順の変換関数をいくつかある Windows ソケット提供示します。次の表は、これらの関数を示します。

Windows ソケットのバイト順の変換関数

Function	目的
ntohs	ネットワークのバイト順のホスト（ビッグエンディアンのバイト順に小さい Endian）に 16 ビットの量を変換します。
ntohl	ネットワークのバイト順のホスト（ビッグエンディアンのバイト順に小さい Endian）に 32 ビットの量を変換します。
Htons	ホストのバイト順のネットワークのバイト順に 16 ビットの量を変換します（ビッグエンディアンに小さい Endian）。
Htonl	ホストのバイト順のネットワークのバイト順に 32 ビットの量を変換します（ビッグエンディアンに小さい Endian）。

この例のもう一つの点が通信のもう一方の端のソケットアプリケーションが非 MFC アプリケーションの場合、次のようにすることは避ける必要がある点です:

ar << pMsg;

pMsg が CObjectクラスから派生した C.C++ オブジェクトへのポインターです。これは、オブジェクトに関連付けられた追加の MFC の情報を送信し、 MFC アプリケーションサーバーは、それを理解されません。

詳細については、次のトピックを参照してください。

参照

概念

MFC における Windows ソケット

次の方法で共有

Windows ソケット : バイトの順序付け

処理命令

バイト順を変換する必要があります。

バイト順を変換する必要がない場合

バイト順の変換の例

参照

概念

その他のリソース