2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ネットワークプログラミング相談室 Port13

1 : ◆FIcNi4f8js :05/03/03 05:05:31
主にソケットに関しての質疑応答スレです。

Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html

Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

過去スレ:
Port12 http://fun.kz/test/read.cgi/tech/1102427855/ ☆新タイプミラー
Port11 http://fun.kz/test/read.cgi/tech/1096187183/ ☆新タイプミラー
Port10 http://fun.kz/test/read.cgi/tech/1090385857/ ☆新タイプミラー
Port9 http://fun.kz/test/read.cgi/tech/1080658835/ ☆新タイプミラー
Port8 http://pc5.2ch.net/test/read.cgi/tech/1073560271/ ★行方不明
Port7 http://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね


2 :デフォルトの名無しさん:05/03/03 05:07:05
図書コーナー!(^O^*)

UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
詳解TCP/IP〈Vol.1〉プロトコル
http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
The Implementation (TCP/IP Illustrated, Volume 2)
http://www.amazon.co.jp/exec/obidos/ASIN/020163354X/
Linuxソケットプログラミング―ネットワークプログラミングにおける実践技法
http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
TCP/IPによるネットワーク構築〈Vol.3〉―クライアント‐サーバプログラミングとアプリケーション
http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
Webプロトコル詳解―HTTP/1.1、Webキャッシング、トラフィック特性分析
http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/

3 :デフォルトの名無しさん:05/03/03 05:08:28
★図書追加
TCP/IPによるネットワーク構築〈Vol.1〉原理・プロトコル・アーキテクチャ
http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/

今までに出てきたURL抜粋

RFC 日本語版リスト
http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
C10K ヘヴィーロードサーバ
http://www.kegel.com/c10k.html
JPNIC RFC関連リンク集
http://rfc-jp.nic.ad.jp/link/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
http://www.studyinghttp.net/rfc_ja/2616/rfc2616_ja.html
IANA Well known port numbers
http://www.iana.org/assignments/port-numbers
MSDN
http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp

ツール類
tcpdump
http://www.tcpdump.org/
Windump
http://netgroup-serv.polito.it/netgroup/tools.html
pathchar
ftp://ftp.ee.lbl.gov/pathchar/
pchar
http://www.employees.org/~bmah/Software/pchar/

4 :デフォルトの名無しさん:05/03/03 05:15:15
★図書
TCP/IPによるネットワーク構築〈Vol.1〉原理・プロトコル・アーキテクチャ
http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
★ツール
Packetyzer
http://www.networkchemistry.com/products/packetyzer/
ethereal
http://www.ethereal.com/
★プログラミング
Raw IP Networking FAQ
http://www.whitefang.com/rin/
★規格
RFC Editor
http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
http://www.freesoft.org/CIE/RFC/
- Randomness Recommendations for Security
http://www.faqs.org/rfcs/rfc1750.html
★プロトコル
TTCP
http://www.sean.de/Solaris/ttcp.html
http://www.kohala.com/start/ttcp.html
★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm
★その他
パタリロ〜クックロビン音頭〜
http://www.fileup.org/file/fup2930.mp3
通報
http://www.cyberpolice.go.jp/

5 :デフォルトの名無しさん:05/03/03 05:17:12
BoostSocket
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket

The Code Project - Internet & Network programming
http://www.codeproject.com/internet/

問題ありのサイト?
ネットワークプログラミングの基礎知識
http://X68000.q-e-d.net/~68user/net/


6 :デフォルトの名無しさん:05/03/03 07:53:01
マルチクライアントのサーバーを作っているのですが、
接続できる最大のクライアント数はFD_SETSIZEで定義される数ですか?

7 :デフォルトの名無しさん:05/03/03 10:47:49
>>6
プログラム的にはそうだけど、OS的には別

8 :デフォルトの名無しさん:05/03/03 10:50:47
あ、嘘ついた。7は無しで。

9 :デフォルトの名無しさん:05/03/03 11:25:16
9様 & >>1

10 :デフォルトの名無しさん:05/03/03 13:36:43
>>7
OSも関係あるんじゃなかったっけか。
WinXPだったら10クライアントまでだっけか。
Linuxだったら無制限だっけか。

11 :デフォルトの名無しさん:05/03/03 13:48:23
>>10
それはライセンスの話で、ソケット的な制限があるわけではない。
それにLinuxだってソケット的に無制限なわけないでしょ。
どうチューニングしようと、カーネルメモリを使い果たしたら終り。

12 :デフォルトの名無しさん:05/03/03 14:28:48
ライセンスの話なのか。
10人以上接続できるやつを作っても10人しか接続できないものだと
今までずっと思ってた。

メモリは詳しくないから分からん。
むしろ「カーネル」のつくものはカーネルおじさんしか知らない。
勉強してきますorz

13 :デフォルトの名無しさん:05/03/03 14:34:47
ttp://www.apache.jp/misc/windows.html
の事を言ってるんだろうな

14 :デフォルトの名無しさん:05/03/03 23:26:54
前スレが終わったのでage!

15 :デフォルトの名無しさん:05/03/04 00:29:45
>>2に追加

TCP/IPによるネットワーク構築〈Vol.3〉
Linux/POSIXソケットバージョン―クライアントサーバプログラミングとアプリケーション
http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/

TCP/IPによるネットワーク構築〈Vol.3〉
クライアントサーバプログラミングとアプリケーション―Windowsソケットバージョン
http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/

16 :デフォルトの名無しさん:05/03/04 22:00:05
winsockの使い方がなかなか覚えられない。
どうやって覚えるのがベストなのさ?

17 :デフォルトの名無しさん:05/03/04 22:02:25
>>16
とにかくやれ

18 :デフォルトの名無しさん:05/03/04 22:02:58
winsockの関数や構造体のほとんどは
UNIXでの名前を再定義しているだけだ。
実はUNIXのコードがほとんどそのまま使えたりする。
close()をclosesocket()に変えるぐらいか。

19 :デフォルトの名無しさん:05/03/04 22:05:17
HTTP 1.0クライアントでも作ってみれば?
コマンドラインならすぐできるでしょ。

20 :デフォルトの名無しさん:05/03/04 22:09:37
>>17-19
Winsockを使ったアプリケーションは今までに3回くらい作ったけど、
全然頭の中に残らないんさorz
winsockはC/C++で使ってるが、ん・・・。
WINAPIならサクサク入ってくるんだけどなぁ。

この際暗記的に覚えるしかないか。

21 :デフォルトの名無しさん:05/03/04 22:13:24
概念を把握してないんでしょ。
ネットワークは抽象的だから。
>>1のFAQを何回も読め。>>15も読んだ方がいい。
これを克服すると一つレベルアップ。

22 :デフォルトの名無しさん:05/03/04 22:22:45
>>18
クソBSDソケットの真似事しても無意味だと気付いたM$は
Winsock2.0の時点でさっさと独自API仕様に乗り換えたぞ

23 :デフォルトの名無しさん:05/03/04 22:28:23
その結果さらに大糞になってしまった。

24 :デフォルトの名無しさん:05/03/04 22:30:06
OSまるごと失敗続きのM$

25 :デフォルトの名無しさん:05/03/04 23:06:45
>>18
ただ、マルチスレッドが多く使われる分野だから・・・
UNIXとWinでは、その辺で移植に困る事があるんじゃない?
あと、fork

26 :デフォルトの名無しさん:05/03/04 23:10:13
>>18は古典的な釣りだよ。相手にしなさんな。

27 :デフォルトの名無しさん:05/03/04 23:13:40
なんでsocket関連使って作られたソースって汚いんだろうね
BSDでもwinsockでも

28 :デフォルトの名無しさん:05/03/04 23:14:45
BSD流は汚くなるけど
最初からwinsockで作られた奴は綺麗

29 :デフォルトの名無しさん:05/03/04 23:15:06
>>27
たとえば?

30 :デフォルトの名無しさん:05/03/04 23:18:45
マクロの使いすぎだよな。
ソースが汚いというのは、記述スタイルの話じゃなくて、
マクロ乱用のことを言ってるんだと思う。

31 :デフォルトの名無しさん:05/03/04 23:22:50
WindowsはSEHあるから、かなりシンプルにまとまると思うけど。

32 :デフォルトの名無しさん:05/03/04 23:25:45
マクロっつーか構造体の構造に一貫性がないと感じる。
なんかこう一本筋が通ってないというのかな。


33 :デフォルトの名無しさん:05/03/04 23:28:42
>>32
あーそれもある。名前のつけ方も刹那的だし。

34 :デフォルトの名無しさん:05/03/04 23:30:22
ひたすら改築増築を重ねてきたからだろうね。

35 :デフォルトの名無しさん:05/03/04 23:30:23
>>21
dクス。
やってみるさ。

36 :デフォルトの名無しさん:05/03/05 00:21:50
>>33
殺那的ワラタ

もっと整合性を考えて欲しいよな。
一から作るC#で直るかと思ったら…orz

37 :デフォルトの名無しさん:05/03/05 03:51:30
C#は次で手が入るっぽい

38 :デフォルトの名無しさん:05/03/05 21:43:47
テキストは送受信できても画像を送受信する方法が分からなくて色々試してたら、
ファイルをWINAPIのCreateFile云々を使ってchar型の変数に読み込んでそれをテキストファイルと同様に扱ったら送れたのですが、
画像はこのchar型変数の中でどうなってるんですか?
文字列として格納されているのですか?
char型変数を使うのが間違ってるのかなと思ったのですが>void型とか?
そこらへんどうなんでしょうか。

39 :デフォルトの名無しさん:05/03/05 21:47:15
「変数」?
「配列」って言いたいの?


40 :38:05/03/05 22:16:40
>>39
すいません、配列です。

41 :デフォルトの名無しさん:05/03/05 22:49:01
テキストだろうがバイナリだろうが、結局はただのバイト列だろ。
つか、ネットワークプログラミング関係無いし。

42 :デフォルトの名無しさん:05/03/05 23:44:48
>>39
の切り替えしにワラタ

43 :デフォルトの名無しさん:05/03/05 23:52:42
int はもっともPCに適したビット数(16 or 32 or 64) OSに依存
long は 32
short は 16
char は 8

配列はただのビット列なので区切りがわからないと扱いにくいから
型を指定してアクセスしやすくるす
charを使うと8ビットづつ shortを使うと16ビットづつといった具合

テクストは単にASCIIが8ビット単位しかないのでcharを使ってるだけ
Unicodeは16ビットになるのでshortになる

つか、ネットワークプログラミング関係無いし。


44 :デフォルトの名無しさん:05/03/06 00:10:24
>>43
>int はもっともPCに適したビット数(16 or 32 or 64) OSに依存
>long は 32
>short は 16
>char は 8

決まっているのは
sizeof(char)==1
char<=short<=int<=long
だけじゃなかったっけ?

つか、ネットワークプログラミング関係無いし。

45 :デフォルトの名無しさん:05/03/06 00:15:41
大嘘をもっともらしく言えるのも、匿名掲示板特有の現象ですよ

46 :デフォルトの名無しさん:05/03/06 00:33:16
もっともらしくすらないけどね。

つか、ネットワークプログラミング関係無いし。

47 :38:05/03/06 01:23:01
ありがとうございます。
えっと・・・char型よりもビット数の大きい型の変数を配列にしてやればいいんですね。

//スレ違いすいませんでした。

48 :デフォルトの名無しさん:05/03/06 08:24:03
>int はもっともPCに適したビット数(16 or 32 or 64) OSに依存

こんなこと言う奴初めて見た
しかもOSに依存ときた・・

49 :デフォルトの名無しさん:05/03/06 09:09:55
>>43
漏れのathlon64はlongが64bitです。どうすればよいでしょうか。

50 :デフォルトの名無しさん:05/03/06 09:28:42
longはint以上の大きさらしい。

long >= int >= short

51 :デフォルトの名無しさん:05/03/06 11:39:45
longも変動するのかしらんかった
intは処理系で一番高速なアクセスができるビット数だと定義されてると思ってたけど違った?
__int64とかって意味ないな

52 :デフォルトの名無しさん:05/03/06 11:43:23
>>51
このドアホ

53 :デフォルトの名無しさん:05/03/06 11:53:37
>>51
もしかしてsizeof(char)==1オクテットとか信じてる?

54 :デフォルトの名無しさん:05/03/06 12:12:20
>>52-53
まあ動けばなんでもいいじゃんw


55 :デフォルトの名無しさん:05/03/06 12:13:41
>>51
スレ違いだからみんな正しい解答なんかしないよ
さっさとどっかに逝け

56 :デフォルトの名無しさん:05/03/06 12:14:22
>>54
そいつが作った稚拙なソースが他人に渡らないのであればな。

57 :デフォルトの名無しさん:05/03/06 12:24:29
>>51
>intは処理系で一番高速なアクセスができるビット数だと定義されてると思ってたけど違った?
もともとの意味はそうなんだけど、int=32bitを前提にしてるアプリが多くて、
互換性に支障をきたすから、64bitな処理系でもintを32bitにする事が多い。

基本ルール
sizeof(char)==1
char<=short<=int<=long
int>=32bit

最後のだけは守らなくてもANSI C準拠になったはず。
C99じゃlong longも正式採用になったしどうなったんだろ?

58 :57:05/03/06 12:25:37
>int>=32bit
longだったかも・・・。
憶えてないや。

59 :デフォルトの名無しさん:05/03/06 12:46:19
いい加減スレ違いだからやめて欲しいけど、
上2段は正しいけど、規定されているのは、short>=16bitとlong>=32bitだけだよ。
intのサイズは間接的に>=16bitと決まるだけ。


60 :デフォルトの名無しさん:05/03/06 12:53:20
このスレ的にはC99を期待できるならintN_tやuintN_tを使えってことでいいんじゃないの

61 :デフォルトの名無しさん:05/03/06 13:10:46
結局誰も正確なことはわからんということでいいのでは?
必要ないしね、開発する処理系のビット数だけ把握してればいい話
まだほとんどint = 32なんだから

62 :デフォルトの名無しさん:05/03/06 13:12:53
>>61
どうしようもないバカだな

63 :デフォルトの名無しさん:05/03/06 13:15:04
んなことわかっててもたいしたソフトも組めないのじゃ意味ないけどねw

64 :デフォルトの名無しさん:05/03/06 13:37:47
こういうクズがのさばれるような業界だから
IT土方って呼ばれるんだよな。

65 :デフォルトの名無しさん:05/03/06 14:10:38
混じれ酢すると
言語仕様をいくら顧客に語ったところで、お金にはならないよ
生産性も向上しないよ、ないようによってはするものもあるけど
技術は技術でもアルゴリズムとかUIの既存以外のアイデアをいくつ持ってるか
応用して作り出せるかのほうが重要
それができないならただ言語仕様に詳しいだけのコーダー(土方)
って発想が普通では?


66 :デフォルトの名無しさん:05/03/06 14:32:08
例えば、IPヘッダのチェックサムなら、
#include <stdint.h>して、uint16_tを使う。以上。

>>65
プログラマ板行け、この呆け。

67 :デフォルトの名無しさん:05/03/06 19:44:35
16bit=>int==16
32bit=>int==32
64bit=>int==32


64bit以外は、確かにCPUにあわせたbit数になるため、最も高速にアクセス出来る。
64bitで最も高速にアクセス出来るのは、long longだ。



68 :デフォルトの名無しさん:05/03/06 19:56:51
大嘘をもっともらしく言えるのも、匿名掲示板特有の現象です

69 :デフォルトの名無しさん:05/03/06 20:15:36
つか、ネットワークプログラミング関係無いし。

70 :デフォルトの名無しさん:05/03/06 20:31:03
>>67って間違いなの?
俺もそう認識してたけど・・・

71 :デフォルトの名無しさん:05/03/06 20:33:07
マジレスすると、>>67は一応正解
http://www.google.com/search?num=50&hl=ja&ie=Shift_JIS&c2coff=1&q=int%8C%5E+CPU+%8D%C5%82%E0%8D%82%91%AC&lr=lang_ja
例外を除いてint型はCPU(OSも)と同じビット数になる。
しかし、64bitは互換性確保の為にint型でも32bitのまま

72 :デフォルトの名無しさん:05/03/06 20:59:42
CPUや吐かれるコード、最適化等に依存じゃないのか?
妄信的に決め付けるのは間違いの元

73 :デフォルトの名無しさん:05/03/06 21:26:47
>>71
そう、OSも と言うのが重要
CPUだけ64bitでも、OSが16bitDOSじゃ意味ネェよ

74 :デフォルトの名無しさん:05/03/06 21:46:26
いや正確にはリンカがライブラリモジュールを結合する際に32,64を区別してくっつけてるから
コンパイラ&リンカに依存してる
ただ普通は64OSなら64コンパイラを使うってことだと思われます。

75 :デフォルトの名無しさん:05/03/06 21:58:14
>>67,>>71 それ正解じゃない。
cray-1 なんかは short==int==long==64bitだった筈。

76 :75:05/03/06 22:03:05
補足。crayの件は、ぐぐったら↓に表があった。
ttp://grizzlyweb.com/webmaster/ccodestd/c_decl.htm
あれ、cray-2 って書いてあるな。まあいいや。
とにかく、そういうマシンもあるってこと。

77 :デフォルトの名無しさん:05/03/06 22:06:31
ぐぐってみたけど, 64OSでint = 32にしてるのは
AMD と Intel が暫定的にやってるだけの話のようだが?

78 :デフォルトの名無しさん:05/03/06 22:21:58
alphaとかでもintは32bitのままだったような。
まあ、DOSは16bitだし。

とりあえず、自分の周辺の事しか知らない
井の中の蛙にはなりたくないね。

79 :デフォルトの名無しさん:05/03/06 22:32:55
>>77
別に暫定的じゃない。こういうABIの根幹に関わる部分は、一度
決めたら二度と変えないものだし。

UNIX系64bit OSは、crayみたいなスーパーコンピュータを除き、
ほとんど全てで short:int:long:pointer=16:32:64:64 てなってる。
alpha, irix(mips64), sparc64, amd64, ia64 すべてそう。
alpha や mips64 が出た当時は、まだ C99 以前、C89の時代だった
から、C言語標準に long long はなかった。
だから、longを64bitにするのが、ほぼ唯一の妥当な解だった。
で、この時代に longを32bitと常に仮定するようなソースコードは、
UNIXの世界からはほぼ一掃されたので、それ以降の64bitマシンも
同様の定義を使うのが慣例。


80 :デフォルトの名無しさん:05/03/06 22:56:20
えーと、みんな気がすんだ?

では何ごともなかったように以下ネットワークプログラミングの話へ

81 :デフォルトの名無しさん:05/03/08 04:05:48
ネットワークプログラムは他者との強調が必要
プラットフォームに依存しない作りにすることを心がけるためにも
以上の話題に無関心なのは困る

82 :デフォルトの名無しさん:05/03/08 04:18:08
そもそもプラットフォームが違えばAPI仕様が根本的に違うので
意識しても無駄
どうしてもクロスなものが必要ならWrapperクラスを使うのが普通だし
そうなると意識する必要もない
よっぽどお馬鹿なことでもしないかぎり問題になることもない
桁数が精度に影響するようなつくりをする時点でいくらそういったことが
わかっていてもはっきりいって論外
桁溢れする可能性のあるものは文字ベースで扱うのが普通ですよ
それにtypdefってのはそういうことのためにあるものだし

83 :デフォルトの名無しさん:05/03/08 04:43:24
散々他の人にバカにされてるのに
まだそんなこと言ってるのか

84 :デフォルトの名無しさん:05/03/08 05:03:17
時には割り切ったコーディングも必要だし
理想を求めるのも必要


85 :デフォルトの名無しさん:05/03/08 09:16:44
てゆうか整数型のサイズどころかAPIまで違ってる
システムの間でも通信はできるし実際やってるわけ
ですが。だからこのスレで話題になるんでしょ。

あとどうでもいいけど整数型のサイズは違う(ABIは
当然違う)が、APIは同じってシステムはかなり多いよ。
UNIX系はそんな感じだし。UNIXとWindowsの間でも
ISO-CとかC++で定義されているAPIは同じなんだし。

86 :デフォルトの名無しさん:05/03/08 11:23:53
>>82
アフォ?

87 :デフォルトの名無しさん:05/03/08 11:45:31
>>85,82
GCCしか使わない人ですか?

88 :デフォルトの名無しさん:05/03/08 12:19:02
>>85
はAPIの意味を根本的に取り違えてると思われます。
クロスプラットなソース書こうと思ったら
#if
VC用
#else
ボーランド用
#else
UNIX系用
#endif

って感じで結局別個に書くか、GygwinやMinGwやkylixのようなWrapperライブラリを
使うことになる
まあたしかに、速度の限界を追求するような例えば、圧縮ツールなんかの場合は
上記のように個別に記載することもあるけどね
ネットワークプログラミングでそこまでやってたらバグの元をわざわざ作るようなもんだ

89 :デフォルトの名無しさん:05/03/08 13:00:54
まぁ個々の実力に合わせて適当なところでライン引けや。

90 :デフォルトの名無しさん:05/03/08 13:25:21
>>89
あほか

91 :デフォルトの名無しさん:05/03/08 14:41:32
前に出ていたがsocket系は刹那的なプログラミングする香具師が多いという意見には同感。
ちょっと作って動けばいいやってそのままブラッシュアップされずに放置、みたいな。
何でいつまでも同じ過ちが繰り返されるんだ?


92 :デフォルトの名無しさん:05/03/08 14:42:55
>>89
つまり低能はプログラミングをするな、ということですね。

93 :デフォルトの名無しさん:05/03/08 15:18:45
>>91
そんだけ開発者にとってめんどっくさいIFだってことだろ。
俺はそうはおもわないんだけども。

94 :デフォルトの名無しさん:05/03/08 16:53:56
BSD socketは概念としてはいいけどAPIはクソだと思うね。

95 :デフォルトの名無しさん:05/03/08 18:55:39
>>94
Unix的な極Primitive指向だもんな。

その代わりにWin32 APIなんかと比べると命令セットの肥大化を
うまく抑えて必要最低限なものだけで済むメリットもある、と。

96 :デフォルトの名無しさん:05/03/08 20:02:40
もともとの意味はそうなんだけど、ポインタ=32bitを前提にしてるアプリが多くて、
互換性に支障をきたすから、64bitな処理系でもポインタを32bitにする事が多い。

97 :デフォルトの名無しさん:05/03/08 20:08:20
>>96
そんなコード、見たことねぇな。恵まれた環境で仕事してるんだなぁ、俺(*´Д`)


98 :デフォルトの名無しさん:05/03/08 21:22:22
ここのみんなは ACE って使わんの?
俺も使ったことはないんだけど、なんかよさげだよ。

99 :デフォルトの名無しさん:05/03/08 21:29:36
64bit UNIX でも 64bit Windows でもポインタは 64bit じゃん。
その「多い」って、いったいどこの処理系の話よ?


100 :デフォルトの名無しさん:05/03/08 21:36:42
しー。
目を合わせちゃ駄目ですよ。

101 :デフォルトの名無しさん:05/03/08 22:17:55
>>99
UltraSPARCとかそうじゃなかったっけ?
32bit互換モードとかあった気がする。

102 :99:05/03/08 22:24:21
32bitモードは、sparc64 に限らず、どのCPUにもあるよ。
でも32bitモードは、「64bitな処理系」じゃない。
単なる「32bitな処理系」。

103 :101:05/03/08 22:34:43
あらら、もしかして>>96
64bitモードでもアドレスをuint32_tとかで扱うってことを言ってるのかしらん。
でも、それじゃ動かないよね?てっきり互換モードの話かと。。。

104 :デフォルトの名無しさん:05/03/08 22:45:01
いや、32bitOS(Win95等)で16bitプログラム(Win3.x用)を動かす、
なんて事は今までも多々あったし、XP64でも当然32bitプログラムは動く。
もちろん、x86に限らず、普通の64bitOS上では
既存の32bitバイナリがそのまま動くのが一般的。

もし>>96が「64bitOS上で32bitプログラムを動かす」ことを言っているなら
ただのバカだよ。
いや、「64bitOS(64bit処理系)でもポインタは32bitにする」と言ってるとしても
ただのバカであることに違いはないけど。

もしかしたら同一人物かもね。
http://pc5.2ch.net/test/read.cgi/tech/1109121175/38-

105 :デフォルトの名無しさん:05/03/08 22:58:22
32bit互換モードってまたIntelの8086セグメント方式が復活するみたいで嫌だな


106 :デフォルトの名無しさん:05/03/08 22:59:34
>>105
バカ

107 :デフォルトの名無しさん:05/03/08 23:09:08
javaでrawソケットって使える?

108 :デフォルトの名無しさん:05/03/09 02:45:49
せっかく64bit使ってるのに32bitの壁なんて考えたくも無い

109 :デフォルトの名無しさん:05/03/09 02:55:09
>>107
具体的には何使うの?
packet caputureなら、http://netresearch.ics.uci.edu/kfujii/jpcap/doc/←がある。

>>93
うーん、ソケットAPIの問題よりも、
ネットワークプログラミング固有の問題の方がずっと障壁になっていると思う。
ヘテロ環境への配慮、failureへの配慮など分散型システム固有の問題が。

集中型システムで頭固まっていると嵌まりやすい。
特に初級を脱却するくらいの時は天狗になっているケースがあって、
過去スレでも暴れる人が何人もいた。

110 :デフォルトの名無しさん:05/03/09 03:43:00
unixソケットはあんまりよく知らないけど
winsockはひどいもんだな
例えば、Asyncにしようとするとウィンドウへイベントって形でやらないといけないけど
クラスにシンプルにまとめようとしたときこれはかなりじゃまになる
接続が成功したか、失敗したか、途中で切れたかって判断がかなり複雑になる
からそのつど、プログラム量がけっこう多くなる
この辺はunixでもいっしょかな?
単純C/Sだとサーバ側がちょっと複雑になるだけですむけど、分散システムになると
もうわけわからんくなるね

111 :デフォルトの名無しさん:05/03/09 04:05:50
UNIXのaio_*は、
http://docs.hp.com/ja/B2355-60104-09/aio.5.html
な感じなら。

例によってprimitive形式で、frameworkまでいってないから、
初級者はパニックだろうね。
俺も正直なところあまりこれといった実績がないね(w

112 :107 :05/03/09 04:47:07
>>109
ありがと

113 :デフォルトの名無しさん:05/03/09 12:12:43
そもそもコネクションが切れるって動作は必要ないと思うんだよね
切れたら、再接続に向かってどうしても繋げない状態を検出したら
その状態を検知した上でabortするような仕組みにすればいいのに
数十秒待たされたあげくに、実は切れてるねんとかいう今の仕組みはよくない
FTPやHTTPはこの切れを前提で作られたプロトコルだからいまさらどうしようもないのだろうけど

114 :デフォルトの名無しさん:05/03/09 12:14:53
これだからトウシロは・・・

115 :デフォルトの名無しさん:05/03/09 12:21:41
>>113
アホは存在すること自体が罪。死ね。

116 :デフォルトの名無しさん:05/03/09 12:22:59
>>113はいくらなんでもネタだろ


117 :デフォルトの名無しさん:05/03/09 15:06:39
>>110
別にAsyncはウィンドウ必須じゃないんだけど。

118 :デフォルトの名無しさん:05/03/10 10:14:28
>>114、115、116
そこを論理的に教えて使えるようにするのがプロの仕事では?










もう教育係いやだ。。。(´Д⊂グスン

119 :デフォルトの名無しさん:05/03/10 10:56:39
>>118
ここは学校でも会社でもないからな

120 :デフォルトの名無しさん:05/03/10 12:48:09
>>117
socketoptで非同期通信にすると当然ぐるぐるまわさないと
即時応答はできない
そうなるとスレッドを使わないといけなくなるわけだが、ぐるぐる回す時点でかなり
リソースの無駄使い
しかもVC++のクラスはスレッドセーフじゃないのでかなりかっちょわるいソースになる

つーか>>114-117はwinsock知らないだろ?

121 :デフォルトの名無しさん:05/03/10 12:56:50
>>120
ハァ?何言ってんだお前。

122 :デフォルトの名無しさん:05/03/10 13:00:22
かっちょわるいのは>>120の脳内だけで勘弁

123 :デフォルトの名無しさん:05/03/10 14:04:01
>>118
では漏れが。
Winsockでウィンドウとメッセージポンプを使いたくないなら(当然使いたくないが)、
・セッション数が少ないならスレッドで普通にselectしつつ動作
・セッション数が多いならWSAEventSelect とかIOコンプリーションルーチンやらを使う
あたりが定番。

サーバアプリなどで性能が要求される場合には、IOコンプリーションルーチンつきの
IOリクエストを常時複数投入しておいて、カーネルが待ち時間無しで随時IO処理できる
ようにすることもある (IOキューイングという手法)。

UI オリエンテットなアプリで、通信のスループットなんかどうでもいい場合にはウィンドウ
メッセージを使う場合もある(のか?やったことないけど)。

124 :デフォルトの名無しさん:05/03/10 16:19:06
>>113 は単に TCP に対する愚痴じゃないの?


125 :デフォルトの名無しさん:05/03/10 16:39:34
>>124
いやしかし、>>113
>切れたら、再接続に向かってどうしても繋げない状態を検出したら
>その状態を検知した上でabortするような仕組みにすればいいのに
ってまさに今のTCPそのもののように思うんだけど・・・
数十秒も頑張らなくて良いよ、ってことなのかな。

126 :デフォルトの名無しさん:05/03/10 19:07:24
>>125
今のTCPのどこがそこまでしてくれるんだ?
コネクション確立っていっても定期的に状態確認しあってるわけでもないし
ちょっと瞬断しただけで、コネクションが切れて
しかもデータのやり取りが発生するまでは無反応
それが今のTCPの仕様

127 :デフォルトの名無しさん:05/03/10 19:15:25
>>126
KeepAliveをONにすればしてくれるでそ。
んで、KeepAlive始めるまでの時間の諸口が長く、またコネクション毎にこの時間を設定できないOS/
プロトコルスタックが殆どで使いにくいのは確かだけど、これはTCP/IPの責任ではないと思う。

じゃあ誰のせいだ、というとよくわからないけど。
TCP/IPのKeepAliveは使わないで上位プロトコルでやるという伝統のせいか?

128 :デフォルトの名無しさん:05/03/10 19:15:54
>>127
訂正: 「使いにくい」⇒「使い物にならない」

129 :デフォルトの名無しさん:05/03/10 19:33:44
ネット速度もかなり高速化してるし
この際、新しいプロトコルを考えてもいいかもね

130 :デフォルトの名無しさん:05/03/10 19:45:45
プロトコロの問題じゃなくて、利用する側の問題だろ。
再接続したければ、再接続すればいい。
>>126は低能だから無視。>>120>>113も同様。

> 再接続に向かってどうしても繋げない状態を検出したら

出来る時はしているのに、
低能ゆえ出来ない時がどういう時か理解できずに見当違いの愚痴を言う呆け。

131 :デフォルトの名無しさん:05/03/10 21:01:53
>>130
ネットワーク高速化してるのに、低脳ゆえ出来るときが多様化してることにも
気づかないのですね?

132 :デフォルトの名無しさん:05/03/10 21:52:46
元気、元気、元気な子供は腋毛がざるそば!
こんにちわ。プロトコロジョージです。

133 :デフォルトの名無しさん:05/03/10 22:54:00
>>129
window scalingとかselective ackとかTCPも進化してるぞ。

134 :デフォルトの名無しさん:05/03/11 00:23:03
ネットワー君です。

135 :デフォルトの名無しさん:05/03/11 00:26:58
>>133
そういう問題以前の戯言と思われ。

136 :デフォルトの名無しさん:05/03/11 00:29:57
再接続ワラタ

137 :デフォルトの名無しさん:05/03/11 01:15:54
最近はNATの内側にいる人が多いから
本来のTCP/IPの再接続が出来ない環境に
なっている人も少なからずいる。
>>113 >>120 >>126
それを知らずに愚痴ってるだけ。


138 :デフォルトの名無しさん:05/03/11 02:33:38
>>137
> 本来のTCP/IPの再接続

って何よ? TCPのRSTのこと?


139 :デフォルトの名無しさん:05/03/11 20:10:56
POP3 に関して質問です。

POP3サーバが LIST コマンドを受けたときに返す、メッセージの
オクテット数についてですが、メッセージの中に "." で始まる行が
あった場合、この "." を2オクテットではなく、1オクテットと数えな
ければならない、っていうことでしょうか?

参考:

http://www.ietf.org/rfc/rfc1939.txt
11. Message Format

http://srgia.fc2web.com/docs/rfc1939j.html#11
11. メッセージ形式

140 :デフォルトの名無しさん:05/03/11 20:24:53
全然血が牛

141 :デフォルトの名無しさん:05/03/11 20:31:32
改行スタイルの話だろう。

142 :デフォルトの名無しさん:05/03/11 20:58:01
>>139
 あってます。multiline response の形式としては、termination octet (.) で始まる行は
先頭にもう一つ termination octet を付けることになっているが、メッセージのオクテット数
を数える上では行頭のtermination octetを2倍に数える必要はない(数えてはいけない)、
ということです。

改行については特に質問されていないようですが、改行は当然2オクテットで数えます。

143 :デフォルトの名無しさん:05/03/11 20:58:19
ラインバッファ方式のサーバもあるから
あんまり長いとバッファオバーフローおこしちゃうでしょ
まあこれくらいにしといてよってことの話でしょ
70以下に抑えときゃまああんま深く考える必要もないかもしれん

144 :デフォルトの名無しさん:05/03/11 21:08:50
>>143
なんか質問とは全然関係ないような気もするが・・・
確かに、以前調べたときは1024バイト程度でJISのシフトINとか無視して
勝手に改行入れてくれるMTAが結構あった。

仕事でMUA作ってたんだけど、そういうので化けてもOKにする必要が
あってメンドクサカッタなぁ。

145 :デフォルトの名無しさん:05/03/13 11:40:39
selectで待ち受けられるディスクリプタの
登録の上限数ってどこに書いてあったっけ

OSはredhat9でカーネルは2.4.26使ってます
何も考えずに800本くらい使ってるけど
このくらいなら大丈夫だったっけか

146 :デフォルトの名無しさん:05/03/13 12:20:43
FD_SETSIZE を再定義しているのであれば、
select 側には特に制限はない。
むしろファイルディスクリプタ数の方の
制限で決まる。

ただ、800ぐらいの数になると、epoll(4)
とか kqueue(2) とか使った方が速い可能性
がある。こいつらは今のところあまり移植性が
ないので、libevent を使うのが吉。
ttp://www.monkey.org/~provos/libevent/

147 :デフォルトの名無しさん:05/03/14 22:30:18
質問です。
MSNメッセンジャーにあるような、NATの種類を判別するプログラムはどのようにすれば良いのでしょうか?
シンメトリックの場合とそれ以外の場合とで処理を別にしたいのですが・・・。

よろしくお願いします。
WinSockで組んでいます。


148 :デフォルトの名無しさん:05/03/14 23:33:01
両端のプログラムを書けるなら出来るかもね

149 :デフォルトの名無しさん:05/03/14 23:35:59
>>148
なんの話?

150 :デフォルトの名無しさん:05/03/15 04:00:54
UDP hole punching

151 :デフォルトの名無しさん:05/03/15 09:35:01
FD_SETの戻り値はなんですか?

152 :デフォルトの名無しさん:05/03/15 10:50:49
0

153 :デフォルトの名無しさん:05/03/15 11:58:32
>>151
マクロなので sys/select.h か sys/types.h あたり見て確認しる

154 :デフォルトの名無しさん:05/03/15 14:07:42
仕様上は戻り値なし(void)と解釈しておいた方が
良いと思われ。引数範囲チェックとかもなし。


155 :デフォルトの名無しさん:05/03/15 19:30:15
>>154
FD_SETを1万回やったらどうなるかなというちょっとした好奇心

156 :デフォルトの名無しさん:05/03/15 19:45:59
100万回生きた猫

157 :デフォルトの名無しさん:05/03/15 21:10:15
質問です。
UDPは到着順も保障されないと言う事ですけど、
これは、送信時に大きなデータをWinsockが勝手に細かく切って送信した場合の到着順も保障されないのでしょうか?


158 :デフォルトの名無しさん:05/03/15 21:12:47
>>157
はい。

159 :デフォルトの名無しさん:05/03/15 21:14:33
フラグメントは、受けとったカーネルが組み立ててから
アプリに渡すので、アプリからみると、分解されてない
ように見える。
もし、フラグメントが一つで途中で失われると、パケット
全体が失われる。


160 :デフォルトの名無しさん:05/03/15 21:23:27
>>159
失われるだけで、順番は正しくなるのでしょうか?
失われるだけだと、再送処理を行えば良いだけなんですが・・・。

161 :デフォルトの名無しさん:05/03/15 21:45:12
>>160
逆に不ぞろいだったとして、カーネルが制御してるものをどうやって順番に並べるの?

162 :デフォルトの名無しさん:05/03/15 22:12:43
>>161
いやー、だからエラー処理は出来ないのかなぁ?と
最初から分割されるサイズを考慮して、プログラムでそのサイズを超えないように分割しないといけないのかな?と

163 :デフォルトの名無しさん:05/03/15 22:13:16
てゆうか、フラグメントに分割されたパケットに
関しては、カーネルが順番どおり並べてくれるの
で問題ない。ただし、全パケット届けば。

パケット損失確率がある程度高いネットワークだと、
フラグメントが失われる→全再送が生じてネットワーク
バンド幅を無駄使いすることが多くおきるので、
UDPの1パケットは、あんまり大きくしない方が良いことが
多い。


164 :デフォルトの名無しさん:05/03/15 23:04:53
バイトオーダーってWindowsもLinuxもFreeBSDもその他PC UNIXも全てリトルエンディアンですか?
CPU依存とのことなのでCeleron, Pentium, Athlon, K6を使うOSは全てリトルエンディアンですよね?

165 :デフォルトの名無しさん:05/03/15 23:07:28
> CPU依存とのことなのでCeleron, Pentium, Athlon,
> K6を使うOSは全てリトルエンディアンですよね?

これは、その通り。

> LinuxもFreeBSDもその他PC UNIXも全てリトル
> エンディアンですか?

Linux や FreeBSD は、PC だけでなくビッグエンディアンの
マシンでも動くので、OS だけからは何ともいえない。


166 :デフォルトの名無しさん:05/03/15 23:22:31
>>165
FreeBSD同士でも企業の使ってるでかい箱とPCとでは
バイトオーダーが違うこともあるということですか?


167 :デフォルトの名無しさん:05/03/15 23:24:46
>>166
当たり前の事を聞くなよ

168 :デフォルトの名無しさん:05/03/15 23:27:30
SPARCで動くFreeBSDが無いわけじゃないからなぁ

169 :デフォルトの名無しさん:05/03/15 23:28:19
互換性のためにエミュレートしてでも同じにしてると思っていたので。

170 :デフォルトの名無しさん:05/03/16 00:05:23
>>169
それは勘違い。
*BSDやLinuxはそういうレベルでの互換性を保ってはいない。



171 :デフォルトの名無しさん:05/03/16 00:36:56
なんとか理解できました。ども>ALL

172 :デフォルトの名無しさん:05/03/16 01:16:59
transactions per secondを一定量にコントロールするコツってなんでしょうか?
多様なバイナリならば、ヘッダ部とデータ部が分かれていると思いますが
1度処理したら次の処理許可まで、ヘッダ部を解析してデータ部は読み捨てを繰り返すしかないのですか?


173 :デフォルトの名無しさん:05/03/16 02:20:39
>>166
ちっちゃいMac miniもPowerPCでビッグエンディアン。


174 :デフォルトの名無しさん:05/03/16 03:06:35
>>172
何の話やねん!?

175 :デフォルトの名無しさん:05/03/16 03:08:04
1秒間に何回同期処理をするか。連投禁止処理だね。

176 :デフォルトの名無しさん:05/03/16 04:42:51
僕のちんちんは大きくならないんでしょうか?

177 :デフォルトの名無しさん:05/03/16 10:43:29
SNMPってポート何使ってたっけ

178 :デフォルトの名無しさん:05/03/16 10:52:18
UDP:161,162

ていうかそんぐらいすぐ見つかるから調べれ。

179 :デフォルトの名無しさん:05/03/16 11:05:03
>>178
ありがと
ググッたらすぐ出てきた。これ有名なプロトコルなのな。
知らなかった世。

これって、UDPだけど双方向にデータやり取りするよね。
どうやってるの? 送信してきたポートに返してるの?

162の方は片方向みたいだけど。

180 :デフォルトの名無しさん:05/03/16 11:52:43
>>179
RFCよめ

181 :デフォルトの名無しさん:05/03/16 13:29:55
>>180
ありがと
RFC日本語見つからなかったからパケットキャプチャしてみた。
これって発信元ポートに返してるんだな。
なんでTCPにしなかったのかな。
ブロードキャスト?とかするから?

182 :デフォルトの名無しさん:05/03/16 14:04:42
なおさら、RFC嫁

183 :デフォルトの名無しさん:05/03/16 14:13:23
>>181
てか、おめぇ調べる気ねぇだろ。
やってる事がずいぶんと半端じゃねぇか?

184 :172:05/03/16 21:01:22
TPSの調節なんてみんなしてないのか。
まあゲームとかチャットとかコミュニティ向けの技術だしな。

185 :デフォルトの名無しさん:05/03/16 23:26:31
>>181
ttp://www.faqs.org/rfcs/rfc3430.html
実装してるの見たことないが。

186 :デフォルトの名無しさん:05/03/17 01:02:09
>>184
何言ってんだ?

突然、

>>172
> 多様なバイナリならば、ヘッダ部とデータ部が分かれていると思いますが

って頭おかしい人かと思ったぞ。「ならば」て

187 :デフォルトの名無しさん:05/03/17 01:08:12
ゴミレスしかできないなら黙ってればいいのにw

188 :デフォルトの名無しさん:05/03/17 01:49:33
でも客観的に見て何を言ってるのか理解の出来ない文章ではあるよ。
目的は何?帯域制限の話?それとも何か別の事?
そして>>172の書いてる俺技術についての中身が全くわからないし。
とりあえずエスパーきぼんぬに該当するなとしか思えなかったからね。

>まあゲームとかチャットとかコミュニティ向けの技術だしな。
これにはちょっと興味がわくので、他の人にもわかるように書きなおしてほしいね。

189 :デフォルトの名無しさん:05/03/17 02:04:39
俺は、なんか問題を間違ったレイヤで解決しようと
しているような印象を受けたな。>>172は、おそらく
制限値以上のレートでパケットが届いたらそれを
無視しようって意味のような気がしなくもないが、
>>186>>188の言うとおり、エスパーきぼんぬと
しか思えない。

まあ、RTPの本でも読んでみたら?
ttp://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
とか。


190 :デフォルトの名無しさん:05/03/17 03:01:51
受信の帯域制限ってソフトウェアで調節できるものなの?


191 :デフォルトの名無しさん:05/03/17 03:16:49
遅くしたけりゃいくらでも遅く作れるべ?相手に待ったをかけれるように作れば。

192 :デフォルトの名無しさん:05/03/17 03:23:26
読み取り量を減らせばそら作れるけど
送受信バッファが溢れる〜ってことになったりせんの?


193 :デフォルトの名無しさん:05/03/17 03:29:31
>>192
それくらい試せるべ?

194 :デフォルトの名無しさん:05/03/17 03:37:12
速度のまったく異なるPCが混在しているこの世の中じゃ

ポイズン

195 :デフォルトの名無しさん:05/03/17 04:31:50
>>193
バッファがページファイル化されて余計だめっぽかった。
むしろ溢れろよと。

196 :デフォルトの名無しさん:05/03/17 05:05:32
いったいどうやったら195みたいな結論に
至ることが可能なんだ?

TCP使ってるなら、受信可能なバイト数は常に
ウィンドウサイズとして受信側のカーネルが
送信側のカーネルに伝えているから、読みとり
を減らせば、ウィンドウが閉じて、送信側が
勝手に待ってくれる。溢れることもなけりゃ、
ページアウトされることもない。少なくとも
UNIX系OSの場合、ソケットバッファに滞留して
いるデータは、物理メモリに常駐しているから。

この場合、まず送信側のカーネルメモリに溜り、
SO_SNDBUF のサイズ越えて溢れそうになったら、
今度は送信を行おうとするアプリケーションが、
送信システムコールを発行するところで止められる。

197 :デフォルトの名無しさん:05/03/17 09:04:10
前から思うんだけど、Winsockって関数自体にタイムアウト設定が出来る仕様があれば便利だよね。
connect()とかrecv()とか、指定時間たっても結果が得られなかったらfailedを返してしまうみたいなオプションがあればどれだけコードがスマートになるか・・・・

なんで実装しないんですかね?


198 :デフォルトの名無しさん:05/03/17 09:08:35
そんなの簡単に実装できるんだから、必要なら
ユーザが実装しろってことじゃなくて?


199 :デフォルトの名無しさん:05/03/17 10:30:58
>>197
selectすればいいじゃん

200 :デフォルトの名無しさん:05/03/17 10:54:16
>>197
激しくガイシュツなんだが、
WinsockのI/0タイムアウトはやばいから気をつけろ。
特に2000Pro以前。詳しくはMSDN読んでくれ。

201 :デフォルトの名無しさん:05/03/17 11:00:43
HTTPは、
503 Service Unavailableの時に
Retry-After: 60
で、retry間隔を指定して、Layer 7でのcongestion control。

202 :197:05/03/17 11:07:33
>>198-199
いやぁ、その処理の為にわざわざ別の関数を持ってきてコード書くんだったら
connect()とかにそういうオプションをつければ行で済むしスマートじゃないかなぁ と。
詰めて三行程度で書ける、たかが三行だけど出来上がったコードはスマートじゃないよね。
接続 と言う目的以外の処理コードがあるんだから・・・。

1つの関数の引数を複雑にするくらいなら、関数の数を増やした方が良い って考えはわかるけど
この程度の為に色々持ち出すのも・・・・。

203 :デフォルトの名無しさん:05/03/17 11:11:04
WindowsのAPIの設計者は>>202と同じような考えの人が結構いますね。
引数が山のようにあって、引数で出来ることと出来ないことに対称性が全くない。

204 :デフォルトの名無しさん:05/03/17 11:45:46
>>202
それが気になるなら、タイムアウトつきの処理を
connect_timedwait() みたいな関数として独立
させて、メインの処理からはそれを呼ぶだけに
すれば?


205 :デフォルトの名無しさん:05/03/17 12:11:01
>>202
そんなこと言いだしたらconnectに限らず時間のかかる全ての関数に
timeout引数が欲しいってことになってくるじゃねーか

206 :デフォルトの名無しさん:05/03/17 12:17:50
int memcpy(void *dst, const void *src, size_t len, const struct timespec *timeout);

207 :デフォルトの名無しさん:05/03/17 12:21:17
>>204
だから、みんなが独自に connect_timedwait() を作るのは馬鹿らしい
ってことでしょ。OS に同梱されているならともかく。



208 :デフォルトの名無しさん:05/03/17 12:22:19
>>204に同意
単純に接続するだけの、connect関数と
その関数に対する待機は別問題とおもう。

209 :デフォルトの名無しさん:05/03/17 12:25:28
connect なりなんなりの、ただ一つの要求だけタイムアウト
待ちしたいというのがむしろ特殊な要求で、むしろselectで
複数待つ方がふつうだから用意するまでもないんでしょ。

210 :デフォルトの名無しさん:05/03/17 12:26:48
いつでもコネクトできるか失敗するまで待つわけでもなかろう。

211 :デフォルトの名無しさん:05/03/17 13:31:45
UNIX Socket FAQ
6.11 Connect with timeout (or another use for select() )

Winsock Programmer's FAQ
2.14 - How can I change the timeout for a Winsock function?

URLは>>1


212 :デフォルトの名無しさん:05/03/17 13:35:32
ちなみにWinsockはタイムアウトじゃなくて非同期ソケット使うのが良いよ。
>>200にも書いたが、タイムアウトが起きると先頭のデータ失うから。(古いWindowsで)

213 :デフォルトの名無しさん:05/03/17 13:53:00
>>207
自分用ライブラリには標準装備した。
簡易的なクライアントソフトってセッション1つで
十分だからselectは接続後にしか使わない
そんな感じ

214 :デフォルトの名無しさん:05/03/17 17:16:46
各自がバラバラに実装するのが馬鹿らしいからこそ、そういう
ライブラリを公開して広く使ってもらえるようにすればいいのに。
Windowsユーザって、なんでそういう発想ないの?

215 :デフォルトの名無しさん:05/03/17 17:32:02
それは、すべてMSの仕事ってわけでもないだろう。
ライブラリライブラリっていうが、
もともと使いにくいと言って出てきた関数は言うなればAPIみたいなもんだろ。

それらを組み合わせ使いやすいように拡張するのがライブラリなのであって、
そのライブラリはMS製だろうが、オープンソース物だろうが関係ないんでは?

Windowsユーザーだなんだって話じゃなく、便利なライブラリがほしいだけ、
そのライブラリ作成者になろうとすら思わない、お前に一つも問題はないっていうのか?

216 :デフォルトの名無しさん:05/03/17 17:36:04
非Windowsユーザではなかろう>>214が(サブとしては持ってる?)
何で>>215のためにライブラリを作るの?


217 :デフォルトの名無しさん:05/03/17 17:37:25
非Windowsユーザであろうだな
なくなくない?みたいな間違いをしてしまった

218 :デフォルトの名無しさん:05/03/17 17:39:17
え、俺メインはLinuxなんだけど・・。いらないよWinsockのラッパライブラリなんて。

219 :デフォルトの名無しさん:05/03/17 17:43:27
あ、>>214が言ってるのは、MSがなぜ用意しないのかってのじゃなくて、
ライブラリ作成者が便利なものつくったのなら、なぜ皆に公開してあげないの?
って言いたいのね、読み違えまくった・・・吊ってくる orz

Windows系の開発者さんたちは、確かにそういう傾向の人多いかもしれないね。


220 :デフォルトの名無しさん:05/03/17 18:59:44
確かに作ってもバイナリ配布が多いな。配布条件も厳しい。

221 :デフォルトの名無しさん:05/03/17 19:07:21
1クライアントにソケットを2つ使うべきか、ひとつで頑張るかで迷ってる。
直感でいいから、きゅぴーんと来たほうを言ってくれ。頼む。

222 :デフォルトの名無しさん:05/03/17 19:10:40
>>221
FTP を見よ。

223 :デフォルトの名無しさん:05/03/17 19:29:13
いやFTPでいうところのPassiveモードだけど、それが何か?

224 :デフォルトの名無しさん:05/03/17 20:38:15
まあ、その場合だと、普通は二つだな。

225 :デフォルトの名無しさん:05/03/17 20:45:14
Broken pipeってどうやって解決したらいいと思う?
FreeBSDの鯖にWinの倉でコネクトした後色々通信してクローズするとそうなります

226 :デフォルトの名無しさん:05/03/17 21:09:55
Broken Pipe が起きるってことは、こちらの返事を相手が
全部読まないうちに、相手側がコネクションを切断してし
まったってこと。正常に通信してても頻繁に起きるような
ら、どちらかがプロトコル処理を間違えてる可能性がある。

FreeBSD 側に関しては、ネットワークトラブルでそういう
ことが起きることはあるし、クライアント側が勝手にこけ
てもそういうことは起きるので、サーバ側としては正しく
動作を継続するために、signal(SIGPIPE, SIG_IGN) として
おく。こうすると SIGPIPE が飛んでくるんではなく、
write(2) や close(2) が EPIPE を返すようになるから、
エラーコードをきっちり見て、きれいに後始末すること。

クライアント側でもネットワークトラブルでそういうこと
が起きることがあるのは同じだけど、この場合、むしろ
サーバー側のプログラムミスの可能性の方が高いかもね。
って Winsock って、Broken pipe の場合どういう反応を
するんだっけか?


227 :デフォルトの名無しさん:05/03/17 21:24:31
例えば、CLOSE_WAIT中にRSTが来た時、
送ろうと思ったけど、何らかの理由で送れなかった時。

228 :デフォルトの名無しさん:05/03/17 21:26:28
half-closeになってねえ?
↓Javaだけど、half-close問題は同じ。
http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/net/articles/connection_release.html

229 :225:05/03/17 22:16:32
ソケット閉じる前に一回リード処理したらBroken pipe出なくなりました
その他色々参考になりました。ありがとうです

230 :デフォルトの名無しさん:05/03/18 00:16:05
>>224
よっしゃ、2つでがんばるよ。
最大で5つくらいまで必要かも知れんけど。

231 :デフォルトの名無しさん:05/03/18 00:17:06
>>226
> Broken Pipe が起きるってことは、こちらの返事を相手が
> 全部読まないうちに、相手側がコネクションを切断してし
> まったってこと。正常に通信してても頻繁に起きるような
> ら、どちらかがプロトコル処理を間違えてる可能性がある。

これ逆だよね。

>>229
half-closeだったってことだね。

232 :デフォルトの名無しさん:05/03/18 00:17:50
>>230
その場合は5つだよ。俺も経験から言って間違いない。

233 :デフォルトの名無しさん:05/03/18 01:18:32
>>231
逆? 合ってると思うけど…

それに half-close とは限らないよ。
1. クライアント側が shutdown(, SHUT_WR) で half-closeする。
2. サーバー側がクライアントになにか書く
3. クライアント側がその内容を読み込む
4. クライアント側が完全に close する。
5. サーバー側がクライアントになにか書く
とすると、5で初めて Broken Pipe になる。
つまり、half-close とは関係なく起きる。


58 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)