| Re: 通信 ( No.1 ) |
- 名前：通 日時：2008/02/26 10:54
先の質問において、
理解できなかった所はどこですか？
すこし漠然としすぎてわからないので。。。
|
| Re: 通信 ( No.2 ) |
- 名前：優柔不断 日時：2008/02/26 18:10
不可能…とまでは行きませんが、ちょっと難しいと思います。
構造体の大きさはOSとかコンパイラで変わってきますから。
|
| Re: 通信 ( No.3 ) |
- 名前：Will 日時：2008/02/26 20:01
> Gamさん
可能です。
intやcharであっても、構造体であっても変数であることに違いは無いですから特に難しくは無いと思いますが。
トライされてみてはどうですか。
> 優柔不断さん
> 構造体の大きさはOSとかコンパイラで変わってきますから。
ちょっと違います。
アライメントはCPU-メモリ間のバス幅に影響されますのでOSとCPUに依存しますが、コンパイルする時にコンパイルオプションを指定することでアライメントを固定にすることも出来ます。(指定しない場合はコンパイルしたPCのアライメントに合わされる)
ただ、コンパイルオプションでアライメントを指定すると全ての構造体がそのアライメントになってしまうので非効率です。
そのため、通信データに使う構造体のみのアライメントを同じにする(パディングされないようにする)手段として私がよく使うのは以下の二つです。
・VC++,C++ builder
#pragma pack(push, 1) // アライメント1バイトに変更する
sturct st_name {
メンバ
};
#pragma pack(pop) // アライメントを元に戻す
・GCC
struct st_name {
メンバ
} __attribute__ ((packed)); // パディングしないようにするための宣言
|
| Re: 通信 ( No.4 ) |
- 名前：Gam 日時：2008/02/26 23:07
質問が漠然としすぎていました、申し訳ないです。
いままで通信に使うデータの判別には
データ詳細文字列の先頭4byteにきまった文字列をいれることでそれを判別していたのですが、
これだとなんだかんだスパゲティーソースになっていってしまいまして(- -；
構造体を送信できるのなら「通信データ型」にあるように、
そこにデータタイプとその詳細をいれておくことで、
受信側はそれを判別＞処理していけないかな、と。
|
| Re: 通信 ( No.5 ) |
- 名前：通 日時：2008/02/27 10:32
そもそもアライメントとはC言語の規格の話では
無いのでパッティングされないようにする手法
の殆どが処理系依存です
パディングされないようにするのは、
移植性・安全性を高める為の常套手段です
しかし、最近のアプリケーションでは、
逆に利用できるOSとマシンをある程度
限定することで、これらを行わない場合も
あります。
これは異なるプラットフォームの通信でしか、
基本的に問題に成らないことを示唆したものです。
これらの問題を脇において置くならば、
構造体や可変長のデータの場合は、自分で
サイズとタイプを管理してしまうのが一番
手っ取り早いと思います。
送受信の判別などであれば、
「通信待ち」というスレッドで私がいくつか
サンプルを書いていますのでそちらを参考に
わからないことがあれば質問していただければ。
ttp://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=664&p=5
|
| Re: 通信 ( No.6 ) |
- 名前：ライブラリ使用者 日時：2008/02/29 01:25
横槍失礼します。
アライメントをそこまで気にする必要あったのですか？
自分は全く考慮なんぞしてませんでしたが。。
Gamさんの質問も、そうした環境を考慮する質問でもないような。
ようは、&(構造体)、sizeof(構造体)を渡せば十分だと思ってるんですが。
アライメントを考慮するケースとしては、
①OS依存のケース
64bitOSとかが該当なのでしょうか・・（該当ケース知らないので何とも。。
②設定として独自にアライメントを変更した場合
でしょうが、
①のケースの場合は、そもそもお互いに通信可能なのか？
例えばですが、
int：4バイト(サーバー)、6バイト(クライアント)だったとしますと、送信受信処理をそれぞれ、4バイト対応と6バイト対応で作成し、それぞれで送受信が必要ということでしょうか。
②の場合ですが、
これは処理を加える必要は無いと思うのですが。。
例
int：6バイトとかでプログラムを作成したとします。
この時、サーバークライアント共に同じ設定でビルドしていますので、サイズズレは発生しませんよね？
ただし、①のような環境依存な場合も併発すると動作しない事に陥ると思いますが。
＞Gamさん
構造体を送信できるのなら「通信データ型」にあるように、
そこにデータタイプとその詳細をいれておくことで、
受信側はそれを判別＞処理していけないかな、と。
これが分かっておられるのであれば、Gamさんが使用した構造体に置き換えれば問題ないと思います。
ただし、「そこにデータタイプとその詳細をいれておく」が重要になります。
通信されるデータはあくまで、バイトデータなのでタイプを入れないと同じデータサイズの構造体を送信した場合に区別がつかなくなります。
既に回答されていることと重複してるかもしれませんが、気になったもので返信してみました。
|
| Re: 通信 ( No.7 ) |
- 名前：Will 日時：2008/02/29 10:51
> アライメントをそこまで気にする必要あったのですか？
同じ人(orグループ)が同じ環境で作った同じプラットフォームでしか動作しないソフト同士でしか通信をしない場合は通さんが書かれている通り何の問題もありません。
優柔不断さんのレスでアライメントに触れられていたので私が過剰に反応しすぎてしまいました。
蛇足でしたすいません。
●以下雑談●
> ①のケースの場合は、そもそもお互いに通信可能なのか？
業務用アプリの話になってしまいますが、業務用では異なるプラットフォーム(Windows,Mac,Linux,Tron,VxWorks等々)、アライメント(16,32,64bit)、エンディアン(Big or Little)
で作られたソフト同士で通信をすることなど日常茶飯事であるため暗黙の了解として以下の約束事があります。(私のいる業界だけかもしれないけど)
①通信データにはアライメントによる不要なパディングを入れない
②エンディアンはBig(モトローラ)とする
②はインテル系CPUしか使わない環境では不必要なんですが、大昔ネット通信に使われるような高性能パソコンはほとんどモトローラであった名残らしいです。
|
| Re: 通信 ( No.8 ) |
- 名前：通 日時：2008/02/29 11:59
いろいろ書いてたのですが、
Willさんが反応してくれたので、
消しました（。＿。；ゴメンナサイ
|
| Re: 通信 ( No.9 ) |
- 名前：ライブラリ使用者 日時：2008/02/29 21:57
いろいろ話がそれてしまいました。
（Gamさんゴメンナサイ
Struct struct
{
・・・(中身はご自由に)
}
struct st;
NetWorkSend(handle、&st、sizeof(struct));
基本的には上記でOKという話です（それまくりましたが。
もしうまくいかないようであれば、また質問してください。
|
| Re: 通信 ( No.10 ) |
- 名前：Gam 日時：2008/03/02 22:20
最近いそがしく、なかなかしっかり目を通せずにいました。すみません。
多くのご回答ありがとうございます。
>>アライメントの話
私にはまだ少し難しい話のようです。
ただ自分の勉強不足を棚に上げないように、
この後、調べてみようと思います。
>>通さん
提示していただいたスレの方、参考にさせていただきます。
回答ありがとうございました。
また何かあったときは質問させていただくかもしれません。
>>ライブラリ使用者さん
ご回答感謝します。
No.9で提示していただいた方法で挑戦していこうと思います。
また質問するかもしれませんが、
そのときはまた返事をいただけるとありがたいです。
それでは、がんばってきます！
|