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

1 ：lmtp：2009/07/07(火) 00:46:28

主にソケットに関しての質疑応答スレッドです。

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/

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

前スレ
ネットワークプログラミング相談室 Port23
http://pc12.2ch.net/test/read.cgi/tech/1230466044/
関連スレ
ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング【教えて!】
http://pc11.2ch.net/test/read.cgi/tech/1086238859/

2 ：lmtp：2009/07/07(火) 00:47:11

3 ：lmtp：2009/07/07(火) 00:47:57

図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
　そのソースコード
　http://www.unpbook.com/src.html
詳解TCP/IP〈Vol.1〉プロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
詳解TCP/IP〈Vol.2〉実装
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714957/
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894716674/
TCP/IPによるネットワーク構築
　〈Vol.1〉原理・プロトコル・アーキテクチャ
　　http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
　〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
　　Linux/POSIXソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/
　　Windowsソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/

4 ：lmtp：2009/07/07(火) 00:50:21

マスタリングTCP/IP RTP編
　http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
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/
Visual Basicではじめるネットワークプログラミング超入門
　http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/

5 ：lmtp：2009/07/07(火) 00:52:19

URL抜粋:
★規格
RFC 日本語版リスト
　http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
　http://rfc-jp.nic.ad.jp/link/
RFC Editor
　http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
　http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
　http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
　http://www.iana.org/assignments/port-numbers

6 ：lmtp：2009/07/07(火) 00:53:30

★プログラミング
C10K ヘヴィーロードサーバ
　http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
　http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
　http://www.whitefang.com/rin/
Java で packet capture
　http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
　http://www.faqs.org/rfcs/rfc1750.html
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/

7 ：lmtp：2009/07/07(火) 00:57:38

★ツール類
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/

★プロトコル
TTCP
　http://www.sean.de/Solaris/ttcp.html
　http://www.kohala.com/start/ttcp.html
UDP Hole Punching
　http://homepage3.nifty.com/toremoro/p2p/firewall.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

8 ：デフォルトの名無しさん：2009/07/07(火) 01:00:45

前スレの>990
そのおかげで腕がある人間が自己評価よりも高く買ってもらえるんで少しうれしかったりする時代でもあるよ

9 ：デフォルトの名無しさん：2009/07/10(金) 05:56:53

RFC嫁で終わってしまうスレ

10 ：デフォルトの名無しさん：2009/07/10(金) 07:50:50

>>9 ちゃいます。
RFCも読まずに偉そうなことが言えるスレ

11 ：デフォルトの名無しさん：2009/07/10(金) 11:17:11

RFCとLinuxは必須ですな。

12 ：デフォルトの名無しさん：2009/07/10(金) 11:35:46

selectとpollのそれぞれのメリットデメリットを教えて！

個人的には書き方のスタイル（好み）の違い以上の差が無いと思う。
結局リスト全部調べないとわかんないし。

13 ：デフォルトの名無しさん：2009/07/10(金) 11:50:17

selectはファイルディスクリプタの個数に上限がある
pollはwin32には無いのでselectより移植性が低い

14 ：デフォルトの名無しさん：2009/07/10(金) 11:55:38

あーディスクリプタ数の話があったですね。忘れてました。

15 ：デフォルトの名無しさん：2009/07/10(金) 14:50:13

犬がRFCに準拠している保証は無い。
やっぱ、4.4BSDぐらいじゃないか、まともに実装されてるOSは。

http://pc12.2ch.net/test/read.cgi/unix/1065245050/
4.4BSDの設計と実装

16 ：デフォルトの名無しさん：2009/07/10(金) 23:37:38

ちょっと質問。

winsock2で、クライアントアプリを作成、send、recv等のブロック型を別スレッド（Thread2)で利用しています。
で、ファイルのダウンロード中などにその接続を中止したいときがあります。
その際、closesocket()でソケットを閉じるだけでいいのでしょうか？
それともメインスレッドやサブスレッド(Thread3)などからshutdownなどを使用し、その後closesocket()で終了させたほうがいいのでしょうか？

クライアントとして接続を途中で中止させる場合の正しい作法みたいのってあるんでしょうか？

17 ：デフォルトの名無しさん：2009/07/10(金) 23:53:22

そのままclosesocketでおk。

18 ：デフォルトの名無しさん：2009/07/11(土) 10:10:03

ちゃんと鯖側がセッション切れで終了処理する事前提だけどな。
QUITとか送らないといつまでも待ち続ける糞鯖プロセスも有るかもだｗｗｗ

19 ：デフォルトの名無しさん：2009/07/11(土) 10:28:42

ヘッポコなNATは手順を踏まないとエントリーがあふれる可能性がある。

20 ：デフォルトの名無しさん：2009/07/11(土) 17:22:11

>>17-19
とりあえず、closesocketのみでもOK、ただし相手によっては手順を踏んだほうが好ましいということですね。
ありがとうございました。

21 ：デフォルトの名無しさん：2009/07/12(日) 15:43:53

今Cで、
子プロセスで受信した情報を親プロセスで読みたいのですが、
調べたところ共有メモリとかいう単語が出てきたのですがいろいろなページを見てもよく理解できませんでした。
shmget(key_t key,int size,int shmflg)の意味もよくわかりません。
keyとshmflgが不明です。どなたか説明お願いします・・

22 ：デフォルトの名無しさん：2009/07/12(日) 15:52:48

>>21
お前、危なっかしいから。勉強するな。
四の五の言わずにファイルに書いとけ。

23 ：デフォルトの名無しさん：2009/07/12(日) 21:55:10

>>21
shm だけあっても同期とる手法覚えないと意味ねぇし
書き込み途中のデータ読んだりするぞ
そもそも、親子に分ける必然性があるのかと....

24 ：デフォルトの名無しさん：2009/07/13(月) 00:23:02

質問。

WSAEventSelectについてなんだけど。
クライアントで使用する場合、

まず　WSAEventSelect(sock,hEvent,FD_WRITE|FD_CLOSE);　で設定しFD_WRITEイベントで必要なデータを送った後、
WSAEventSelect(sock,hEvent,FD_READ|FD_CLOSE);　に設定しなおして受信を待つのが普通なのか？

WSAEventSelect(sock,hEvent,FD_READ|FD_WRITE|FD_CLOSE);　にした場合、
まず読み込むデータがないのだからFD_READは来ない。
＞アプリケーションは最初の FD_WRITE 通信イベントの設定から、送信で WSAEWOULDBLOCK （英語）が返されるまで送信可能だとみなすことができます。
というのがあるからFD_WRITEはすぐに来るだろ。
で、送信が終わって、相手サーバがレスポンスを返してきたときFD_READが来て受信出来る。
けど、もうこちらから送信するデータがないのにFD_READとFD_READの合間にFD_WRITEが発生した場合はどうすればいいのかな？

こちら側で送信データがない場合は　FD_WRITEで処理が終わったときに
WSAEventSelect(sock,hEvent,FD_READ|FD_CLOSE);　に再設定しちゃうのが普通なのだろうか？

ちょっと判りにくい文で申し訳ないけど。

25 ：デフォルトの名無しさん：2009/07/13(月) 00:50:46

えーと、EventSelectに限らず、(他のOSでのselect系での場合も含めて)ノンブロッキングにした場合

まず、最初のwriteは普通成功する(ただし、全部送れるとは限らない)。
そして、以後のwriteが失敗した場合(ERROR_IO_PENDINGとか)に
「初めてFD_WRITEを待つ動作」を行う。
ただし、AsyncSelectだと、connect直後にFD_WRITEが来たかな。最初のwrite用に。

要は、「通常時は常に送信可能」と思っておいて
「一旦送信不可と返された時だけ、FD_WRITEを待つ」というやり方にすればよい。
「送るデータが何も無いのにFD_WRITEを待つ」なんてのは、まったく意味が無い。

26 ：デフォルトの名無しさん：2009/07/13(月) 01:10:38

>>25
ありがとう。
つまり送るデータがない場合は、WSAEventSelect(sock,hEvent,FD_READ|FD_CLOSE);　に設定するってことなのかな？

・・略・・
WSAEventSelect(sock,hEvent,FD_WRITE|FD_CLOSE);

while(WaitForSingleObject(hEvent,INFINITE)!=WAIT_FAILED)
{
　if(WSAEnumNetworkEvents(sock,hEvent,&events) == SOCKET_ERROR)
　{
　　if(events.lNetworkEvents & FD_CLOSE)
　　{
　　　・・略・・
　　}
　　if(events.lNetworkEvents & FD_READ)
　　{
　　　・・略・・（受信）
　　}
　　if(events.lNetworkEvents & FD_WRITE)
　　{
　　　・・略・・（送信）
　　　if(送信するデータがなくなった==true) WSAEventSelect(sock,hEvent,FD_READ|FD_CLOSE);
}
・・略・・

27 ：デフォルトの名無しさん：2009/07/14(火) 15:19:15

httpプロトコルでサーバ側のディレクトリを丸ごと
ダウンロードする方法はありますでしょうか？
GETはファイルのみですよね？
サーバ側にIndexOf /を出力する設定にして自力で
辿るしかないのでしょうか。

28 ：デフォルトの名無しさん：2009/07/14(火) 17:11:11

wget

29 ：デフォルトの名無しさん：2009/07/14(火) 17:45:20

>>27
無い。無いものはない。終了。

30 ：デフォルトの名無しさん：2009/07/14(火) 18:07:23

ディレクトリを知る方法が無いなら無理だわな

31 ：デフォルトの名無しさん：2009/07/14(火) 18:08:37

cgiで作るとか
WebDAVでも入れる

32 ：27：2009/07/14(火) 18:44:17

>>28
wgetは検討中です。
wgetでダウンロードを実際に行わずにディレクトリツリー
だけ取得できるようなオプションがあれば良いのですが
そのような事は可能でしょうか？

>>31
webdavはサーバ側のディレクトリの作成には対応してますが
サーバ側のディレクトリのダウンロードもいけるのでしょうか？

33 ：デフォルトの名無しさん：2009/07/14(火) 18:53:27

キーワード分かったんだからオウム返ししてないで自分で調べろよ

34 ：デフォルトの名無しさん：2009/07/14(火) 20:16:31

任意の鯖の/が丸見えに出来たら怖い罠。

35 ：デフォルトの名無しさん：2009/07/14(火) 22:32:55

この際、ftpで。

36 ：デフォルトの名無しさん：2009/07/14(火) 22:38:32

httpプロトコルでサーバ側のディレクトリを丸ごと
ダウンロードする方法はありますでしょうか？
GETはファイルのみですよね？
サーバ側にIndexOf /を出力する設定にして自力で
辿るしかないのでしょうか。

httpプロトコルで
httpプロトコルで
httpプロトコルで

37 ：デフォルトの名無しさん：2009/07/14(火) 23:53:55

>>36
お前恥ずかしい

38 ：デフォルトの名無しさん：2009/07/15(水) 00:34:29

>>36
HTTPプロトコルがいいんだー、ふーんHTTPね

じゃぁ、rfc2616読むといいよ
いろいろ書いてあるから

39 ：デフォルトの名無しさん：2009/07/15(水) 01:01:06

HTTプロトコルプロトコル

40 ：デフォルトの名無しさん：2009/07/15(水) 13:54:24

鯖側で/丸見えにしたら、世界中から丸見えで恥ずかしいと思うよ。
httpプロトコルで丸ごとコピーのプロトコル？を通せば(ry

41 ：デフォルトの名無しさん：2009/07/17(金) 09:07:27

int listen(sockfd,backlog);
backlog=0とするのはご法度ということですが
バックログをゼロにしたいときはどうしたらよいでしょうか。

42 ：デフォルトの名無しさん：2009/07/17(金) 10:16:23

> backlog=0とするのはご法度ということですが
聞いたこと無いなぁ。

43 ：デフォルトの名無しさん：2009/07/17(金) 10:24:28

バックログがゼロということは、接続を一切受け付けられないということでは？
受け付けた接続を保持するキューのサイズのはずだから

44 ：41：2009/07/17(金) 10:34:48

>>43
おっしゃるとおりです。
ようするにlisten()して最初の接続を受け付けた段階で
2つ目以降の接続を受け付けたくないんですが
実際にはaccept()する前にいくつもの接続を受け付けてしまう
（クライアント側からはconnect()が完了したように見える）
のを抑止したいんです。

45 ：デフォルトの名無しさん：2009/07/17(金) 11:04:02

>>41
acceptしたあとlistenを再度呼び出して0に再設定すればいい…
と記憶しているが、実際に試した事は無い。

46 ：デフォルトの名無しさん：2009/07/17(金) 11:08:11

acceptしたあと、listenしなければいい。

47 ：デフォルトの名無しさん：2009/07/17(金) 11:33:44

acceptしたあと、ソケットを閉じてしまえばいい

48 ：デフォルトの名無しさん：2009/07/17(金) 12:07:05

僕は耳と目を閉じ口をつぐんだ人間になろうと考えたんだ

49 ：41：2009/07/17(金) 14:39:57

>>46-47
それも考えたのですが、接続が2本連続で来たとき
・listen()で待ち受け開始
・1本目接続
・2本目接続
・accept()で1本目
・listenポートをclose()
とすると2本目の人がかわいそうかなーって。

>>45
うまく動作すればcloseよりはスマートっぽいので試してみる

50 ：デフォルトの名無しさん：2009/07/17(金) 15:54:49

Winsock2ではlistenの再呼び出しでバックログ数を変更できないらしい

http://msdn.microsoft.com/en-us/library/ms739168(VS.85).aspx
> If the listen function is called on an already listening socket,
> it will return success without changing the value for the backlog parameter.
> Setting the backlog parameter to 0 in a subsequent call to listen on a listening socket
> is not considered a proper reset, especially if there are connections on the socket.

51 ：デフォルトの名無しさん：2009/07/18(土) 03:43:11

そこでUDPですよ

52 ：デフォルトの名無しさん：2009/07/18(土) 19:41:20

WinsockのソケットＩＤをの使ってるポート番号が知りたいんだが出来る？

53 ：デフォルトの名無しさん：2009/07/18(土) 19:57:12

>> WinsockのソケットＩＤ

Windows じゃ、やろうとか思ったことないけど、相手側の事言ってるんだったら
accept() の返りとか, getpeername() とかで何とか何ないの?

# Winsock 中の getpeername の有無はしらん

54 ：デフォルトの名無しさん：2009/07/18(土) 20:14:27

回答者はコード出せ

55 ：デフォルトの名無しさん：2009/07/18(土) 20:28:11

ちゃんとした質問でもないのに何いってんだか

56 ：デフォルトの名無しさん：2009/07/18(土) 21:10:38

悪戯で煽ってる奴じゃないか？
最近あちこちにいるぞ。

57 ：デフォルトの名無しさん：2009/07/18(土) 22:10:16

nine ライブラリてどうなの？使いやすい？

58 ：52：2009/07/18(土) 23:18:06

自己解決した

59 ：デフォルトの名無しさん：2009/07/19(日) 10:10:04

http://pc12.2ch.net/test/read.cgi/tech/1247438792/
C/C++の宿題片付けます 129代目

60 ：デフォルトの名無しさん：2009/07/19(日) 14:51:13

Winsockを用いてプログラムを作成してます。

strData
{
int　　　　　　Count;
int　　　　　　Param;
}

上記のような構造体を送信し、受信できるところまで確認したのですが、
文字列も送信したいと思っています。

strData
{
int　　　　　　Count;
int　　　　　　Param;
CString　　　Text;
}

そこで上記のようにCStringデータを追加したのですが、
CString部のデータのみ正しく受信できません。（送信しできているかも怪しいです）

そもそも上記のようなCStringを含んだ構造体は送受信可能なのでしょうか？

61 ：デフォルトの名無しさん：2009/07/19(日) 14:56:19

CStringってVCのやつだっけ？
VCスレで聞いたほがいいんじゃない・・・

62 ：デフォルトの名無しさん：2009/07/19(日) 15:00:46

PODでないもの送るな

63 ：デフォルトの名無しさん：2009/07/19(日) 16:15:00

>>60
構造体ってのはサイズが固定されてるという大前提がある形の定義で
固定されてるからこそ価値がある存在だから可変するような使い方は出来ない
その場合CStringのポインタが割り当てられるだけ
送信側のポインタを相手に渡しても相手には中身は分からない

64 ：60：2009/07/19(日) 17:27:37

>>63
CStringの本体を送信しているのではなく、ポインタを送信してる訳ですか。
可変長の文字列を送信する場合は構造体に含めず、別途送信する必要があるんですね。

解りやすいご回答ありがとうございました。

65 ：デフォルトの名無しさん：2009/07/19(日) 17:28:57

質問内容的にキツイ人なら氏ねって返されるレベルだから気をつけてね
まあおれのことだが

66 ：デフォルトの名無しさん：2009/07/20(月) 13:27:26

２～４人対戦ぐらいのお手軽ネットゲームを作りたいんだけど、
サーバ用EXE, クライアント用EXEとか分けずに、一つのEXEで対応したい。
その場合、クライアントとして起動したEXEはまあいいとして、
サーバとして起動した場合、自分のデータはサーバに送る必要がないから云々と処理するよりも、
すなおにサーバソケットとクライアントソケット両方つくって、
サーバスレッドとクライアントスレッドを両方動かすほうがいいよね？
クライアントは常に127.0.0.1に接続する感じで、
「自分のデータをサーバに送信、サーバから結果をクライアントに送信」をひとつのEXE内ですませるような。

67 ：デフォルトの名無しさん：2009/07/20(月) 14:40:52

いいけど、マルチスレッドならシングルスレッドのときと同じようにlistenしても固まるだけだからな
詳しくはWSAAsyncSelectでｇｇｒ

68 ：デフォルトの名無しさん：2009/07/20(月) 14:58:58

いま select+recv+send を無限ループでまわして、それを beginthread で包み込んでるんだけど、
結局 WSAAsyncSelect とおなじこと。。だよね？

69 ：デフォルトの名無しさん：2009/07/20(月) 15:00:24

ポーリングをOSに任せるか自分でやるかの違い

70 ：デフォルトの名無しさん：2009/07/20(月) 16:26:43

ポ～ラ♪

71 ：デフォルトの名無しさん：2009/07/20(月) 17:15:08

TCPのURGフラグを使ってる上位プロトコルって何かありますか？
telnetとか？

72 ：デフォルトの名無しさん：2009/07/21(火) 01:49:00

クライアント用ソケットを 127.0.0.1 につないで数バイトぐらいのデータを send する
（この関数は成功し、すぐに処理が戻ってくる）
サーバ用ソケットは別スレッドで作ってあって、そのスレッドの中で recv でずーっと待ってる
（関数から制御が戻ってこない状態）んだけど、
クライアントから send されたデータがいつまでたっても recv できないんです。
で、懲りずに何回かクライアントから send してると、1, 2秒ぐらいたってから思い出したように
全部まとめて recv するみたいなんですが、

そもそも同一マシン内で送受信しているのになぜここまで時間がかかるのでしょう？
なにか思い当たるフシはありますか？

73 ：デフォルトの名無しさん：2009/07/21(火) 02:24:03

NagleアルゴリズムとかTCP_NODELAYでぐぐってみれば？

74 ：デフォルトの名無しさん：2009/07/21(火) 08:32:53

>>72
送信側で毎回PSHフラグを立てればいいと思う
http://support.microsoft.com/kb/411582/ja

75 ：デフォルトの名無しさん：2009/07/21(火) 14:25:07

TCP_NODELAYなんてフラグがあったんですね　試してみます。

PSHフラグって、実際に転送されるパケットの中身を直接操作する必要がありますよね？？
どうやるのでしょう？それともフラグをたてるための関数が...?

76 ：デフォルトの名無しさん：2009/07/21(火) 17:00:13

>>75
>>74のリンク先を途中でやめないで最後まで読むといいよ

77 ：デフォルトの名無しさん：2009/07/21(火) 17:02:35

あ、レジストリ変更しないとダメなんですね.... どうもありがとう！

78 ：デフォルトの名無しさん：2009/07/21(火) 17:37:22

>>77
受信側の処理と送信側の処理は分けて考えないと。

レジストリの変更が必要なのは、PUSHフラグのないパケットを受信側でなんとかする場合。
送信側での遅れを減らすには setsockopt() で TCP_NODELAY をセットすればいいので
レジストリを変更する必要はない。

79 ：デフォルトの名無しさん：2009/07/22(水) 08:26:58

TCPのRFC793読んでるんですが、ESTABLISHED後は、
フラグが何も入ってないデータ入りパケットもやってくる場合がある
って解釈でいいですか？

80 ：デフォルトの名無しさん：2009/07/22(水) 10:05:50

>>79
SEGMENT ARRIVES に書いてあるだろ。
読みにくいなら状態遷移図起こせ。

81 ：デフォルトの名無しさん：2009/07/22(水) 10:59:15

segment text(訳の方もセグメントテキスト)ってのがそうなんでしょうか？
この用語の説明がなくてわけが判らなかった
テキスト＝データってことか

82 ：デフォルトの名無しさん：2009/07/22(水) 11:30:41

>>79
ESTABLISHED後はフラグ無しデータパケットの受信を
「期待している」というのが適切な表現だと思う。

フラグ無しデータパケットというのは、
要はユーザデータ(socketとのsend/recvで渡されるデータ)のことね。
で、(closeを発行することで)FINフラグの立ったパケットを受信すると
コネクション解放手続きが始まると。

83 ：デフォルトの名無しさん：2009/07/22(水) 13:45:07

誰か>>82をガンダムでたとえてくれ

84 ：デフォルトの名無しさん：2009/07/22(水) 15:02:47

http://takeshima.2ch.net/test/read.cgi/news4vip/1248238158/l50

85 ：デフォルトの名無しさん：2009/07/23(木) 01:56:26

一応正常系はできた気がする
疲れました

86 ：デフォルトの名無しさん：2009/07/23(木) 03:17:04

FINフラグ付きパケットを大量に送りつける攻撃も有るぉ。
種癌で言うとザフトの要塞にザフトカラーのメビウスが大量に押し寄せてくる感じ。

87 ：デフォルトの名無しさん：2009/07/23(木) 17:29:02

FreeBSD で、UDP で blocking-recv してるソケットを
別スレッドで close してもブロックしたままなんだけ
ど、これって select 介さないと駄目なんだっけ?

88 ：デフォルトの名無しさん：2009/07/23(木) 17:31:09

FPSや格ゲーのネットワークの同期に関する資料って
どんなキーワードでぐぐったらいいのかな
mmo,fps,ネットワーク,ラグ,同期あたりでググってるんだけど
まともに見つかったのは↓くらいで・・

sourceエンジンのネットワークの資料らしい
ttp://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:jp

89 ：デフォルトの名無しさん：2009/07/23(木) 18:12:23

>>87
そのへんの仕様は知らないけど、自分宛にダミーのパケット送ってやれば
ブロッキング解除されるんじゃないか

90 ：デフォルトの名無しさん：2009/07/23(木) 18:16:36

>>89
ということはモニタ変数みたいなのが必要なわけね…

91 ：デフォルトの名無しさん：2009/07/23(木) 18:25:09

>FreeBSD で、UDP で blocking-recv してるソケットを
>別スレッドで close してもブロックしたままなんだけ
>ど、これって select 介さないと駄目なんだっけ?

volatile fd;

92 ：デフォルトの名無しさん：2009/07/23(木) 18:38:59

>>91
blocking-recv から制御返って来てないのにそれ関係無いでしょ

93 ：88：2009/07/23(木) 19:05:34

誰かしらんかなぁ・・・格ゲーとかどうやってんだろ

94 ：デフォルトの名無しさん：2009/07/23(木) 19:14:29

>>91
volatileに何を期待してるんだ

95 ：デフォルトの名無しさん：2009/07/23(木) 19:17:06

>>88
ntp

96 ：デフォルトの名無しさん：2009/07/23(木) 19:58:19

closeするスレッドとreceive-blockingしてるスレッドは
マスタ・スレーブ(親子)の関係にあるのかな？
もしそうならマスタスレッドは(ソケットのcloseではなく)
単純にスレーブスレッドを殺せばいいんではないかと。

97 ：デフォルトの名無しさん：2009/07/23(木) 20:25:34

多分、shutdown(s, SHUT_RD)で所望の動作が得られる。

98 ：デフォルトの名無しさん：2009/07/23(木) 20:46:04

>>95
質問の仕方が悪かった

今考えてるのはCSで
クライアント上の描画がなるべく自然に公平になるような
それでいて同期が取れているような仕組みがないものかなーと

例えば格ゲーで攻撃されたときにのけぞったりするけど
そのパケットが届くころには実際は攻撃された場所にはいなかったりで
とんでもないところでのけぞったりするわけで
こういうのはどういう仕組みで解消されてるのか説明されてるサイトなり
資料なりないものかと・・

99 ：デフォルトの名無しさん：2009/07/23(木) 20:50:29

解消されてない

100 ：デフォルトの名無しさん：2009/07/23(木) 20:58:32

>>99
納得した。ありがとう
なんとかごまかしごまかしやってみる

101 ：デフォルトの名無しさん：2009/07/23(木) 21:02:43

サーバに届いた時間と移動ベクトルとで予測時間で処理すれば
大抵は上手く動いてるように見える
pingが短くて大量に送りつけられるクライアントが有利なのは仕方が無い

102 ：デフォルトの名無しさん：2009/07/23(木) 21:25:16

>>97
うまくいった。shutdown() 試したつもりだったけどバグってたわ(w

103 ：デフォルトの名無しさん：2009/07/23(木) 23:47:22

http://www10.ocn.ne.jp/~mitinoie/RPGProject.zip

以下のようにすると、全てのデータがクイラアントに届かないことがある。送るたびにデバッカーで止めると届くんだが、解決策がわからない。いい方法がないか教えてほしい。

//ほかのユニットがいることを伝える
foreach(KeyValuePair<string,Session> kv in _sessions)
{
if (kv.Value.socket.isconnected() == false || kv.Value.using_char == false) continue;
units.enumUnit(0, 0, _maps[str[1]].m.width, _maps[str[1]].m.height, (uid, u) =>
{
if (uid == kv.Value.player.id) return;
kv.Value.socket.send("SpawnUnit," + uid + "," + u.x + "," + u.y + "," + (int)u.dir + "," + (int)u.type + "," + u.sprite + "," + u.name + ";");
});
}

104 ：デフォルトの名無しさん：2009/07/24(金) 02:10:07

全部がリアルタイムは無理だな。
全部の入力を見て、演算して送り返す頃には十分遅延している。
自分だけはリアルタイムで処理。周りは鯖経由で遅延した情報で処理で誤摩化すしか。

105 ：デフォルトの名無しさん：2009/07/24(金) 09:58:47

>>103
socketのsendはすべてのデータを送るとは限らない。sendの戻りを確認すべし。

106 ：88：2009/07/24(金) 10:17:00

質問なげっぱもなんなので考えたことのオナニーチラ裏長文すまそ

当たり判定自体はsourceエンジンのラグ補償の考え方を適用する
例えばAがBにスタンしたとすると
サーバー側がAとのレイテンシを考慮して
Aの画面でBへのスタンがちゃんと当たってるか計算する
これはレンテンシが一定の場合はBの位置情報を送ってるのがサーバーなので
正常に計算できるはず

で、問題なのはここからでBはどこでスタンすべきか。色々思いつくものを・・
①Aの画面でスタンしたBの位置（情報はAが送る）
②Aの画面でスタンしたBの位置（サーバー側で送った位置情報から取得）
③Aがスタンしたというパケットをサーバー側が受け取った時点のサーバーが保持するBの位置
④BがスタンされましたというパケットをBに送り、その時点の位置をBからサーバーに送ってもらう
⑤BがスタンされましたというパケットをBに送り、Bに届いたとサーバー側で推測される時点のBの位置

107 ：デフォルトの名無しさん：2009/07/24(金) 10:28:28

①と④はセキュリティ的にやりたくないので却下
また①～③はAの画面で激しくゴムヨーヨー現象やワープが起きるのでこれもあまりやりたくない
となると残りは⑤
⑤は分かりにくいのだが当たり判定自体は攻撃者のAの画面を優先し（ラグ補償）
位置情報自体は被攻撃者のBの画面を優先する。
デメリットはAから見てスタン後にすべること

サーバーからAへのレイテンシがta(ms)、Bへのレイテンシがtb(ms)だとする
⑤の方法はAの画面でスタンをぶちかました時点を0とすると
サーバーにその情報がたどり着くのがta（ここで当たり判定確定)
さらにBへ届くのがta+tb（Bの移動はここまで有効）
ta+tbまでのBの移動情報がサーバーに届くのがta+tb*2（この時点までサーバーはBの移動パケットを許容する）
さらにAにBの移動情報が届くのが(ta+tb)*2
このとき初めてBがスタンしたのをAは見ることができるが
BはAの画面でスタンを発動した位置からta+tbの間に動ける距離離れた場所でスタンする

まぁ・・なんてややこしんだろう
要するに当たり判定は攻撃者視点、位置情報は被攻撃者視点を優先した場合ってことで
ゲームによって優先すべきものが違うと思うが
今回のわたしのゲームはこれでやってみます
ping高いプレイヤーがいるとすべりまくるね。ワープしまくりとどっちがいいのか・・

108 ：デフォルトの名無しさん：2009/07/24(金) 10:50:02

>>103
見たとこ、受信側も悪い
送ったデータはブツ切りで届くことがあるから、
1行の区切り文字が来るまでバッファに溜めておかないとだめ

109 ：デフォルトの名無しさん：2009/07/24(金) 12:46:14

>>105
確認してみたのですが、全て送られてました。

110 ：デフォルトの名無しさん：2009/07/24(金) 12:53:11

108 の言うように
TCPなら　1回の send で送れた量 != 1回の recv で得られる量　なので
受信側はバッファリングして　終端記号や　ヘッダ＋サイズ　で切り出さないといけない

111 ：105：2009/07/24(金) 13:05:54

だったら、デバッグ実行でＯＫなところから見て、複数のsendがRecvでまとめられてる可能性もあるね。丁度、>>108と反対の現象もおきる。

112 ：103：2009/07/24(金) 14:04:26

>>111
ログをとってみたら、見事にまとめられていました。なので、受信する部分をこのようにしてみました。ですが、NPCの出現を10以上にするとでなくなります。

private void recive(string remoteip,byte[] bytes, int len)
{
string str = Encoding.Unicode.GetString(bytes,0,len);

//区切り文字まで届いてるか確認する
if (str.IndexOf(';') == -1)
return;

string[] line = str.Split(new string[] { ";" }, StringSplitOptions.RemoveEmptyEntries);
for (int i = 0; i < line.Length; i++)
{
string[] splitted = line[i].Split(new string[] { "," }, StringSplitOptions.None);
_scm.broadcastNotify(new object[] { ScreenRequst.RECEIVE_PACKET, splitted });
}
}

追記
アップしているほうも更新しておきました。URLは103と同じです。

113 ：デフォルトの名無しさん：2009/07/24(金) 14:10:52

>>112
ｿｰｽ見てないけど
1回の受信で
　[まとまり][まとまり][半端
もあるわけで、recve 後 "[半端" を次の recv 時に付け足す
FIFOﾊﾞｯﾌｧを想定しないとまずいんじゃないかな？

114 ：デフォルトの名無しさん：2009/07/24(金) 14:17:50

>>112
区切り文字まで届いてないからって、そのデータを捨ててはいけない
どこかに取っておいて、次に来たデータと合わせて処理する (次は、前の続きからのデータしか来ない)
届いてた場合も、最後に残った半端な行は次に来るデータと合わせるために同じように取っておく

例えば "ABC", "DEF", "GHI" という3つのデータをsendしたとすると、
recv側は "ABC", "DEF", "GHI" と受け取るかもしれないが、
"AB", "CDEFG", "HI" と受け取るかもしれないし、
"ABCDE", "FGHI" と受け取るかもしれないし、
"A", "B", "C", "D", "E", "F", "G", "H", "I" と受け取るかもしれない
どこで分断・結合されても対処できるようにしないといけない

115 ：デフォルトの名無しさん：2009/07/24(金) 15:56:16

>>112
ソース見てないけど、自分でrecv関数を操作するよりも、
C標準ライブラリのfdopenでソケットをFILE *にした後、
fgetsやfscanfで読み込んだ方が簡単にプログラミングできるよ。
改行コードが届くまで受信プロセスをブロックしてくれるから。

116 ：デフォルトの名無しさん：2009/07/24(金) 15:57:09

バッファのサイズはどれくらいが適当ですか？
1536byteくらい？

117 ：デフォルトの名無しさん：2009/07/24(金) 16:45:21

>>116
今のところはチマチマ考えず、ドッカーンと確保すればいい。
たとえば想定される「最大メッセージ長 * 2」を数kbyte単位で切り捨て。
4kbyte(4096byte)くらい用意しておけばいいんじゃね。

今回のは実験、演習、あるいはホビーのプログラミングなんでそ？

118 ：デフォルトの名無しさん：2009/07/24(金) 17:55:14

>>115
おそらくネトゲを作ってるんだろうからブロッキングでは済まないんだと思われるよ。

119 ：デフォルトの名無しさん：2009/07/24(金) 19:23:59

>>118
んー、確かにLAN内なら無問題だけど、Internet環境だと
パケット遅延があるから、>>115の方法だと、
1行を組立てる間に数百msのブロックが発生する可能性があるね。
格ゲーだったら大問題になる。

ただ、今はまずプログラムを「論理的に正しく動かす」ことが先じゃないかと。
想定される問題は忘れないように検討課題としてメモしてブロッキングの話は
(今は)置いておき、どんどん前進すべきじゃないかと思う。

後から(C標準ライブラリに代わる)非ブロッキング入力対応の論理に変更するのは、
状態「初期/組み立て中/完了」を持つステートマシンを設計すれば(設計できれば)
比較的容易に実装できるだろうし。(>>113の言うFIFOバッファの実装の事ね)
たぶん、ネトゲなら1プロセス内で各プレーヤを疑似マルチタスク
(今時の言葉ではファイバー(?))として実装させることになると思うから、
その時一緒に。

もちろんマルチスレッド構成で実装するのなら、各スレッドはブロックされても
かまわないわけだし。

120 ：デフォルトの名無しさん：2009/07/24(金) 21:32:19

>>115
失念してました。
.NET Frameworkの非同期ソケットを使ってます。

121 ：115：2009/07/24(金) 23:10:29

そう言われて>>103,112を見たら、明らかにCじゃありません。
勝手にC言語だと思い込んでいました。あぁ恥ずかしや....。
こちらこそ失礼しました。

.NETは知識がありませんが、ソケットからデータを読み込み、
もし改行コードがあれば(1行分の組み立てが完了したなら)、
それを解読してメッセージ受信というイベントを
(プレーヤの?)タスクへ通知するという基本的な考え方は共通だと思います。

後は他の人にまかせて、漏れは落ちます。デハ、サラバ

122 ：デフォルトの名無しさん：2009/07/24(金) 23:42:56

今更だけど、
>>82
少なくともACKが入ってないと破棄対象になる。

123 ：デフォルトの名無しさん：2009/07/25(土) 00:52:01

このネトゲで不正をやらかすにはどうすれば良いか考えたほうが楽しそうだ。
FINとかACKのパケット大量に送りつけるだけで沈黙しそうだが。

124 ：デフォルトの名無しさん：2009/07/28(火) 17:58:30

Winsock2を使っています。
UDPで大きなデータグラムが送られてくるとき、
recvfrom側では分割受信することはできないのでしょうか？
たとえば、3000バイトのデータグラムを受信するのに、
100バイトのバッファで全データを受信したいのですが

GetLastError()では234(0xea データがさらにあります。 )となってしまい、
続けてrecvfromを行うとブロックしてしまいます。

125 ：デフォルトの名無しさん：2009/07/28(火) 18:03:27

できません。
全体を格納できるバッファを用意するしかない。
はみでた分は捨てられる。
続けて行うとブロックするのは次のデータグラムを待ってるだけ。

126 ：デフォルトの名無しさん：2009/07/28(火) 19:18:22

>>124
最大の大きさが分かってるんだから、分割する必要は無い。
普通のetherのパケットだと1500バイトくらいまでしか送れないよ。

127 ：デフォルトの名無しさん：2009/07/28(火) 19:26:03

V6でも?

128 ：デフォルトの名無しさん：2009/07/28(火) 19:35:13

>>125-126
ありがとうございます。
UDPは送られてくるパケットが到達しないことがあるという前提に乗っかって、
GetLastError()で234がきたら、そのパケットは無視してバッファを倍増する
みたいな実装はスマートじゃないですよね？
どんな実装をするのが良いのでしょうか。やっぱりTCPですか？

129 ：デフォルトの名無しさん：2009/07/28(火) 19:45:39

窓のくせになんでそんなバッファけちるわけ？
UDPということだから一切受けないという方法もある

130 ：デフォルトの名無しさん：2009/07/28(火) 19:53:37

>>129
いえ、実際にはsendが50kbくらいで、recvが10kb程度を想定してました。
バッファをスタックにとっていたのでサイズを気にしていたのですが、他ではあまりスタックを使わないので大して意味のないこだわりだと思います。

131 ：デフォルトの名無しさん：2009/07/28(火) 20:20:14

>>128
受信バッファサイズとパケットの(必ず相手に届くという)送達保証とは
別々に検討しなさい。

ユーザデータ長がEthenetフレーム(>>126が言うように1KBちょっと)を
越えるようであれば、(UDPではなく)TCPを使うのが定石。

もし(組み込み機器などで)リソースに制限があり、TCPドライバが
実装できないためにUDPを使用せざるをえない場合には、
(UDPの上位にある)アプリケーション層で送達確認機能を実装する。
具体的にはTFTPが参考になる。(もちろん受信バッファサイズは固定。)

でもWindowsなんでしょ？であれば素直にTCPで設計しなさい。

132 ：デフォルトの名無しさん：2009/07/28(火) 21:15:39

>>126
＞普通のetherのパケットだと1500バイトくらいまでしか送れないよ。

んな訳あるかい。df立てない限りフラグメントされる。

133 ：デフォルトの名無しさん：2009/07/28(火) 23:39:11

>>132 MTU変更を要求するアプリってかなり我侭だろ。

134 ：デフォルトの名無しさん：2009/07/28(火) 23:42:58

MTU変える必要ないだろ。

135 ：デフォルトの名無しさん：2009/07/29(水) 03:42:52

変えちゃってるユーザも多いから、動作しないと困るかもね。
ADSLとか非力NASとか。

136 ：デフォルトの名無しさん：2009/07/29(水) 03:54:36

>>133
んな訳あるかい

137 ：デフォルトの名無しさん：2009/07/29(水) 09:12:15

>>133
フラグメントがどのレイヤで発生するのか、勉強し直せ。

138 ：デフォルトの名無しさん：2009/07/29(水) 10:14:20

ビッグパケットとか想定してもしょうがないしなあ

139 ：デフォルトの名無しさん：2009/07/29(水) 19:41:39

クライアント側のマシンからネットワーク越し(TCPを想定)に
サーバ側マシン命令を送って（例えば move とか）
サーバ側マシン上においてOpenGLで描画されている3DCGを動かす
プログラムを作りたいと思っています。

この場合，サーバ側は，マルチスレッドにするしか方法はないのでしょうか？
クライアントから命令がくる→OpenGLに反映
はマルチスレッドじゃないとむりぽ！？

えろいひと、よろしくおねがいします。

140 ：デフォルトの名無しさん：2009/07/29(水) 19:49:25

別にマルチスレッドじゃなくてもいいと思うけど、
OpenGLをマルチスレッドで動かすほうが面倒じゃね？

141 ：デフォルトの名無しさん：2009/07/29(水) 20:00:35

>>139
シングルプロセス/シングルスレッド構成でも実現できると思うが、
想定している言語(C/C++/Java/Ruby/ObjC)や
プラットフォーム(Win/Linux/MacOSX)を明記してくれないと
アドバイスのしようがない。

142 ：デフォルトの名無しさん：2009/07/29(水) 20:04:58

>>140, >>141
早速のご回答ありがとうございます。

iPhone上のOpenGL ESで描いたCGを母艦マシン(MacOSX)から
操りたいと考えています。
そのため，仕様言語はObjective-Cになります。

スレッド・プロセスまわりの話しに詳しくないので
何が最適なのか戸惑っています。

もうしわけありませんが、ご教示いただければ幸いです。

143 ：デフォルトの名無しさん：2009/07/29(水) 20:05:25

>>141
結局は何もつくれないに一票

144 ：デフォルトの名無しさん：2009/07/29(水) 20:18:56

もしUNIX系(Linux/MacOSX)でプロトタイピングを作成するのであれば、
Rubyがお勧め。標準でdRuby(分散オブジェクト)があるし、
OpenGLはRuby-GNOME2で実装されている。
プロジェクトが構想段階なら検討してみては？

145 ：デフォルトの名無しさん：2009/07/29(水) 20:28:47

iPhoneでRubyは動かないんじゃね？

146 ：144：2009/07/29(水) 20:55:34

>>145
リロードしてなかった....orz

147 ：デフォルトの名無しさん：2009/07/29(水) 20:55:45

Pythonがお勧め。

148 ：デフォルトの名無しさん：2009/07/29(水) 22:03:03

>>142
iPhone向けの開発経験は無いけどReference Libraryを漁ってみた。

まずNSProx/NSConnectionで分散オブジェクトが簡単だろうと思ったが、
iPhoneOSのFoundation FrameworkにはNSConnectionクラスが見当たらない。
次にCFNetwork(Core Foundation)にはHTTP/FTP/Web Service向けのクラスは
存在するけど、どれもクライアント側のプロトコルしか実装されていない。

結論として、直にTCPソケット(CFStream)を操作して独自のプロトコルを
実装するしかないと判断する。(TCPコネクション確立はiPhone側から開始)
送受信メッセージのエンコーディングには、PropertyListを利用するのが
良いと思われる。(想定転送データ量によってバイナリ/XML形式の選択を決断)

で、最終的に質問のマルチスレッディングの要否についてだけど、
run loopにコールバック関数を登録する事で非同期I/Oが実現できるから、
結論として「マルチスレッディング無しで実装可能」と判断する。
iPhone Reference Libraryにある文書"CFNetwork Programming Guide"の
章"Preventing Blocking When Working with Streams"を参照してみてください。

実際に試した訳ではないので(すべて推測なので)、間違ってたらゴメソ

149 ：139：2009/07/29(水) 22:37:08

みなさまご回答ありがとうございます！

>>148
ここまで調べて頂きありがとうございます！
やってみます。

150 ：148：2009/07/29(水) 23:23:04

あと全体のアーキテクチャ設計について助言すると、
MacをクライアントそしてiPhoneをOpenGL表示サーバと位置づけ、
メッセージの対話形態としては「要求/応答/通知」方式にするのが良いと思う。
具体的には、Mac上のアプリケーションが表示メソッドを呼び出すと、
要求メッセージが送信され、iPhone上の表示サーバで要求された描画処理が
完了すると応答メッセージを返信する。またiPhone側からアプリケーションへ
イベントを発行したい場合(たとえば処理中断ボタンがタップされた)には、
通知メッセージを送信する。

おそらくX-Window Systemのコアプロトコルが参考になる。
意外にもWikipediaの文書が充実しているので、一読を勧めます。

ttp://ja.wikipedia.org/wiki/X_Window_System_コアプロトコル

RPCと分散オブジェクトを(Foundation Framework無しに)自力で実装する
わけですから、もしも汎用的な「リモートOpenGL表示システム」の設計を
目指すとしたら、かなり大変な作業になると思います。
でも、がんばって挑戦してみてください！！

151 ：デフォルトの名無しさん：2009/07/30(木) 11:51:42

「C言語で２ｃｈに書き込みたいのですが」からやってきたんですが、
2chに書き込めない原因がわかりません。誰か手伝ってくれますか？

http://www1.axfc.net/uploader/Sc/so/22688.zip

152 ：デフォルトの名無しさん：2009/07/30(木) 12:36:02

153 ：デフォルトの名無しさん：2009/07/30(木) 12:45:04

　　　　ヾミ || || || || || || || ,l,,l,,l 川〃彡|
　　　　　V~~''-山┴''''""~ 　　ヾニﾆ彡|　　　　　　　手伝う・・・・・・！
　　　　 /　二ー―''二　　　　　ヾﾆニ┤　　　　　　手伝うが・・・
　　　 <'-.,　　￣￣　　 _,,,..-‐､　〉ニﾆ|　　　　　　　今回　まだ　その時と場所の
　　　/"''-ﾆ,‐l 　　l`__ニ-‐'''""` /ニ二|　　　　　　　指定まではしていない
　　　|　==＝､!　　`＝====､　　l =ｌべ=|
.　　　| `ーﾟ‐'/　　 `ー‐ﾟ―' 　　l.=lへ|~|　　　　　　　そのことを
　　　 |`ー‐/　　　　`ー――　　H<,〉|=|　　　　　　　どうか諸君らも
　　　 |　　/　　　､　　　　　　 l|__ノｰ|　　　　　　　思い出していただきたい
.　　　| ／`ー　~　′　　＼　　　.|ヾ.ニ|ヽ
　　　 |ｌ　下王l王l王l王lヲ｜　　|　ヾ_,|　＼　　　　　つまり・・・・
. 　　 |　　　　≡　　　　　　　　　|　　 `l　　＼__　　　我々がその気になれば
　　　　!、　　　　　　　　　　 _,,..-'′ ／l　　　 |　~'''　そのzipを開くのが
‐''"￣|　`iｰ-..,,,＿,,,,,....-‐'''"　　／　 |　　　 |　　　 10年後　2chが無くなってからということも
　-―|　　|＼　　　　　　　　　／　　 |　　　　 |　　　可能だろう・・・・・・・・・・ということ・・・・！

154 ：デフォルトの名無しさん：2009/07/30(木) 12:52:01

まずクッキーの終わりに改行？

155 ：デフォルトの名無しさん：2009/07/30(木) 12:55:12

>>154
無かったね。218行目と357行目付近にWriteSz("\r\n");を追加。

156 ：デフォルトの名無しさん：2009/07/30(木) 13:30:43

for(it++; it != cookie.end(); it++)
{
wsprintf(buf, "; %s=%s", it->first.c_str(),
url_escape(it->second).c_str());
WriteSz(buf);
}

これって cookie.end() にもデータはあるんだろ？

do
{
・・・処理・・・
}while(it != cookie.end()); じゃね？

157 ：デフォルトの名無しさん：2009/07/30(木) 13:37:09

map::end()にはデータはないよ。
http://www.cplusplus.com/reference/stl/map/end/

158 ：デフォルトの名無しさん：2009/07/30(木) 13:40:09

そうか、じゃあ>>156はなしで

159 ：デフォルトの名無しさん：2009/07/30(木) 14:32:19

とりあえず、>>155とクッキーのパラメータのとこのurl_escapeを外したら書けるみたいよ

160 ：デフォルトの名無しさん：2009/07/30(木) 14:34:07

あーあとNAMEとMAILのクッキー書いてるの外したわ

161 ：デフォルトの名無しさん：2009/07/30(木) 14:35:19

まあ時間制限で書けなかったみたいだし関係ないとは思うが

162 ：デフォルトの名無しさん：2009/07/30(木) 16:06:02

おれが153のAA貼ったとたん優しくなりやがって
天邪鬼どもが

163 ：デフォルトの名無しさん：2009/07/30(木) 16:16:41

>>159-160
アップしてくれ

164 ：デフォルトの名無しさん：2009/07/30(木) 16:23:55

age

165 ：デフォルトの名無しさん：2009/07/30(木) 16:25:02

>>163
何でやねん、数行しか変わってないがな。
うまくいかんのならそう書けば。
そうそう、pc11.2ch.net を pc12.2ch.netに変えたりもしたけど。

166 ：デフォルトの名無しさん：2009/07/30(木) 16:43:23

馬鹿に凶器持たせるようなことすんなよ・・・

167 ：デフォルトの名無しさん：2009/07/30(木) 23:04:22

select() を使って recv() すると WSAEWOULDBLOCK って出ないはずですよね？

168 ：デフォルトの名無しさん：2009/07/30(木) 23:15:36

>>167
非同期系ではそういう幻想を持たないほうがいい。

169 ：デフォルトの名無しさん：2009/07/30(木) 23:20:34

>>168
そうなんですか。あるんですか。。
デバッグ中にブロックされていないはずの recv() が WSAEWOULDBLOCK を
返すところを見ちゃった気がするのですが気のせいだと思ってました。　orz

170 ：デフォルトの名無しさん：2009/07/30(木) 23:45:35

届いてたけど拾いにこないから捨てちゃったとか？
通常ありえないよ。
デバッガで止めてたからとか。

171 ：デフォルトの名無しさん：2009/07/31(金) 00:45:32

>>169
戻りを確認するifを入れて実際に起きるかどうか確認すればいい。

172 ：デフォルトの名無しさん：2009/07/31(金) 11:25:21

>>165
「ＥＲＲＯＲ：ブラウザを立ち上げなおしてみてください。」
て出てきてできなかった。

http://www1.axfc.net/uploader/Sc/so/23023.zip

173 ：デフォルトの名無しさん：2009/07/31(金) 22:26:18

>>170-171
確かにデバッガで止めてはいたのですが。。
色々調べてみるとWin9x系では起きるがNT系では起きないとか
select()はブロックされない事を完全には保証しないとか。

サンプルプログラム等をみるとselect()は非ブロックキングソケットを
使うのが前提となっているみたいですな。
ブロッキングされないのが保証されるのならブロッキングソケットでも
問題ないはずですが。

174 ：デフォルトの名無しさん：2009/07/31(金) 22:32:30

ブロッキングだからこそselect必須。
ブロックされないのが保証できないなら、インターネット動いてねーわ。

175 ：デフォルトの名無しさん：2009/08/01(土) 00:04:37

>>173
ブロッキングの意味を間違えて理解してる気がする。

あと、
>select()はブロックされない事を完全には保証しないとか。
という一文についても、日本語の解釈が誤っているのでは？
これは、ソケットにデータが到着していないにもかかわらず、
selectが戻ることがある(=ブロッキングを保証できない)、
という意味だと思う。言い換えると、selectが戻っても
いざreceiveしてみると受信データ長=0になることも時にはあるから、
その場合はもう一度selectをかけておくれ、を期待しているのではないかな。

最後におせっかいを言うと、何かトラブルが発生したとき、
「....だから、問題ないはず」という思い込みは解決のさまたげになる。
「....だけど、どこかに問題があるはず」という発想でいこうよ。

176 ：デフォルトの名無しさん：2009/08/01(土) 00:20:24

>>175
受信データ長=0はfinがきたってこと。
それでもう一度selectって処理は普通しない。
そうでなければTCP的に言えば受信データ長0ってのは
確認応答しかありえない。これは上位レイヤーに届くことはない。

と言ってみる。

177 ：デフォルトの名無しさん：2009/08/01(土) 00:28:02

平たく言えばアプリケーションレイヤで何かを受信した場合、
長さ1以上はデータ、0は通信の終了を意味する。
TCPがデータストリームの実装だという事を忘れている。

178 ：デフォルトの名無しさん：2009/08/01(土) 00:40:25

>>176
では、
>いざreceiveしてみると受信データ長=0になることも時にはあるから、
の部分は、
>いざreceiveしてみるとエラー(EAGAIN or EWOULDBLOCK)になることも時にはあるから、
に訂正する。

179 ：デフォルトの名無しさん：2009/08/01(土) 12:10:55

「ＥＲＲＯＲ：ブラウザを立ち上げなおしてみてください。」って出てきて
2chへの書き込みができない。誰か助けて！

http://www1.axfc.net/uploader/Sc/so/23023.zip

180 ：デフォルトの名無しさん：2009/08/01(土) 13:02:00

http://pc12.2ch.net/test/read.cgi/tech/1247438792/
C/C++の宿題片付けます 129代目
http://pc12.2ch.net/test/read.cgi/tech/1242876647/
いろんな言語で宿題スレ
http://pc12.2ch.net/test/read.cgi/tech/1197620454/
C#,C＃の宿題片付けます。

181 ：デフォルトの名無しさん：2009/08/01(土) 13:10:28

Linux だと「select が『読める』といっても read で
ブロックすることあるよ」って書いてあるな。

182 ：デフォルトの名無しさん：2009/08/01(土) 13:25:00

>>180
宿題スレに書けと？　宿題じゃないんだけど。

183 ：デフォルトの名無しさん：2009/08/01(土) 16:22:15

>>181
これか・・・
http://www.linux.or.jp/JM/html/LDP_man-pages/man2/select.2.html
>データが到着したが、検査でチェックサム異常が見つかり廃棄された
>時などに起こりえる。

一体どこで検査してんだ
破棄したなら上に投げるなよｗ
明らかに違反してるだろ
時など、って他にもあるなら書けよ
省略すんなよ

184 ：デフォルトの名無しさん：2009/08/01(土) 18:40:57

宿題じゃなくても丸ごと依頼するなら宿題と同じだ。
自分でネットの勉強ぐらいしろよ。

185 ：デフォルトの名無しさん：2009/08/01(土) 18:51:30

>>182 >>179
http://pc12.2ch.net/test/read.cgi/tech/1224449899/

186 ：173：2009/08/01(土) 20:36:54

>>181
それって酷い気がする。
NT系だとブロックしないらしいけど念のためwoodblockは
スルーするように実装しました。

187 ：デフォルトの名無しさん：2009/08/02(日) 05:48:55

>>183,186
Linux TCP/IPドライバの中の人を擁護してみると、
一般論としてselectを前提にしたAPI(ソケット/デバイス/ライブラリなど)の場合、
selectでREAD可能を返したのにread操作でデータ無しとなってしまう事態は、
どうしても避けることができないケースが存在しえることを理解してほしい。
今回のLinux TCP/IPドライバの場合、受信割り込みの延長でのチェックサム計算は
(システム全体の応答性能を劣化させるから)避けたかったのだろうと推測する。

だから最近のAPIでは(特にGUI向けAPIでは)、APIの内部でevent loop & selectを実行し
本当にデータが到着した場合にだけ(事前にアプリケーションが登録した)
call back関数を呼ぶという方式が増えているのだと思う。
この方式であれば今回のselectの問題だけでなく、このスレでたびたび話題となっている
受信メッセージの組み立て処理もAPI側で吸収できる(アプリケーションから隠蔽できる)
利点がある。

188 ：デフォルトの名無しさん：2009/08/02(日) 08:35:44

>>187
> 今回のLinux TCP/IPドライバの場合、受信割り込みの延長でのチェックサム計算は
> (システム全体の応答性能を劣化させるから)避けたかったのだろうと推測する。

割り込み処理は, 読み込んだ物理層のフレームをソケットバッファにつないで
ソケットバッファ持ってるプロセス(スレッド)を起こすだけ.

IPヘッダやさらに上位の層のチェックサムはプロセスコンテキストで計算して
る

到着したセグメントを捨てた後, 再度新規セグメントの入力待ちに移行する方
法を選択しなかっただけ.

おそらく, 初期の腐りきったスタックの挙動と互換性を取る為だとおもわれる.

189 ：デフォルトの名無しさん：2009/08/02(日) 09:02:37

腐りきったってw
TCP/IPのタイムアウトの設定なんかかなり古いもんを引きずっている気がする。
connect()なんてタイムアウトまで待ちきれなくて自分で切ってるし
TIME_WAITなんかも長く居座り過ぎだし。
今のギガビットのネットワークにはそぐわないな。

190 ：デフォルトの名無しさん：2009/08/02(日) 09:20:05

>>189
> TIME_WAITなんかも長く居座り過ぎだし。
RFC で 2MSL と決まってる

191 ：187：2009/08/02(日) 09:28:17

>>188
詳しい解説ありがとう。TCP/IPドライバの実装に詳しそうだから教えてほしいのだけど、

>割り込み処理は, 読み込んだ物理層のフレームをソケットバッファにつないで
>ソケットバッファ持ってるプロセス(スレッド)を起こすだけ.
とありますが、起こすのはシステムプロセス(システムスレッド)でいいのでしょうか？
もしアプリケーションプロセスだと、そのプロセスが監視(select or recv)していない時は
フレーム受信キューに溜まりっぱなしになってしまう訳だから。

ただ、そうだとすれば、チェックサム計算はシステムプロセスで実行して
エラーであれば破棄し、正常であれば(上位の)ソケット受信キューへつないで
アプリケーションプロセスを起こすように実装していれば、
(チェックサム計算エラーに限定すると)今回のselect問題は発生しなかったように思えます。
その辺が自分にはよく分からないのですよ。

192 ：デフォルトの名無しさん：2009/08/02(日) 10:07:53

>>191
> とありますが、起こすのはシステムプロセス(システムスレッド)でいいのでしょうか？
そだよ.

> フレーム受信キューに溜まりっぱなしになってしまう訳だから。
どっちにしても, 受け取る奴がいないとたまりっぱなし
window size = 0 で ack 返して送信側がそれ以上送らないように制御する
UDP だと黙って捨てる

> エラーであれば破棄し、正常であれば(上位の)ソケット受信キューへつないで
> アプリケーションプロセスを起こすように実装していれば、

BSD 系の実装だとそうなってるし, Linux も 2.0 から 2.2 へ移行するときの
大幅にスタック書き換えたタイミングで, そうゆう実装をする選択枝も可能
だったはず.
ソース眺めても, そんなに大変な変更じゃないし………

結局は, 過去との互換性を取ったって事ではあるまいか?

193 ：デフォルトの名無しさん：2009/08/02(日) 10:14:35

玉味噌な人だな～

194 ：187,191：2009/08/02(日) 10:21:39

>>192
過去との互換性ですか。
もしTCP/IPスタックの実装を参考にしようと思ったら、
(Linuxではなく)BSD系のコードを追ったほうが良さげですね。

どちらにしてもスレから脱線した質問ですので、これで終わりにします。
レスありがとうございました。

195 ：デフォルトの名無しさん：2009/08/02(日) 11:54:18

いや、こういう挙動の話はためになる
もっと続けて欲しい

196 ：デフォルトの名無しさん：2009/08/02(日) 12:26:02

ネットーワークプログラミングってアンドキュメントなお決まり事があったり、
ネットで拾えるサンプルプログラムがDQNな実装(特に.Net系)だったりするので
挙動が分かってないと苦労しまするよ。

197 ：デフォルトの名無しさん：2009/08/02(日) 12:27:58

>>187
> 受信割り込みの延長でのチェックサム計算は(システ
> ム全体の応答性能を劣化させるから)避けたかったの
> だろう

昔組み込み向けネットワークドライバを Linux でクロ
ス開発してて、テストとして Linux のパケットをルー
プバックデバイス経由で RAW ソケットで読んでもチェッ
クサムが合わなくてさぁ…。

FreeBSD でやったら一発で通って「なんじゃそら」って
なもんでしたよ。

198 ：デフォルトの名無しさん：2009/08/02(日) 12:32:20

本採用な鯖でlinuxが使われない理由がなんとなく判った

199 ：デフォルトの名無しさん：2009/08/02(日) 12:35:21

>>198
そうなん？
Linux鯖って結構稼動している気がするが。

200 ：デフォルトの名無しさん：2009/08/02(日) 15:15:26

いまどき、IPはもちろん、TCPチェックサムまでは、送信受信ともハードウェアの仕事でしょ。
パケット生成時にチェックサム作るなんてことしない。
その辺考慮してないと197みたいなことになる。

201 ：デフォルトの名無しさん：2009/08/02(日) 15:57:39

基本的な質問だと思うけど、うまく見つけられなかったのでおせーてください。

自分のルータのグローバルIPアドレスを外部鯖にHTTP接続して取得したいのだけど、
【IPのみ】をページ表示してくれる有名な鯖とかってある？

本当はホスト名を一発表示してくれるとこがいいけど、
まーAPIでなんとかなるんでとりあずIPで！

202 ：201：2009/08/02(日) 15:59:44

上の文章だとわかりづらかったので補足。

IPのみというのは、IPアドレス以外の無駄な情報が無いってこと。
正規表現とかHTMLパーサーとか使うのが面倒なので・・・。

203 ：デフォルトの名無しさん：2009/08/02(日) 16:02:16

ルータに聞けばいいじゃない

204 ：201：2009/08/02(日) 16:03:50

>>203
汎用的な方法がしりたいんでつ
いろいろな場所で使いたいので、ルータ固有となるとちょっと・・
SNMPも一般向けのルータにはあまりないらしいので。

205 ：デフォルトの名無しさん：2009/08/02(日) 16:25:49

>>204
汎用的な方法は、自分のルータのグローバルIPアドレスを
Dynamic DNSに登録して、その名前でIPアドレスを検索すること。
登録するドメインは自分で取得してもいいし、借りてもいい。

おそらく自宅鯖を外部からアクセスしたいんだとエスパーするけど、
汎用的な方法はこれしかない。

DNSへの登録が嫌で、なおかつ汎用的でなくても良ければ、
自分で安いレンタル鯖を借り、要求元のIPだけを返すCGIを置けばいい。

いずれにしても板違いの質問だよ。
自宅サーバ板/通信技術板/ネットサービス板へドーゾ。

206 ：デフォルトの名無しさん：2009/08/02(日) 16:27:38

>>200
へぇ～、そんなハードもあるんだ。。
一般のパソコンにも実装されてるの？

207 ：デフォルトの名無しさん：2009/08/02(日) 16:35:00

>>201
そういうサーバを立てればいいだけじゃね？

208 ：デフォルトの名無しさん：2009/08/02(日) 16:38:38

>>200
> いまどき、IPはもちろん、TCPチェックサムまでは、送信受信ともハードウェアの仕事でしょ。
> パケット生成時にチェックサム作るなんてことしない。

NAT とかどうすんのさ。仮想レイヤは? 一々ハードウェ
アレイヤまで落すのか? そもそも NIC 持ってないマシ
ンでの SLIP とかどうすんの?

209 ：デフォルトの名無しさん：2009/08/02(日) 16:42:49

DDNSは運用面で問題有るから、うざいのが本音だな。
基本reject_hostに入れてる。

犬のTCP/IPスタック周りの挙動は怪しいよな。学習用のminix由来じゃしょうがないが。

210 ：デフォルトの名無しさん：2009/08/02(日) 16:48:04

>>209
> 学習用のminix由来

Minix なめんな（w
http://www.minix3.org/

211 ：デフォルトの名無しさん：2009/08/02(日) 16:50:58

DDNSをreject_hostに入れるって何の話よ

212 ：201：2009/08/02(日) 16:52:57

>>205 >>207
板違いなのに答えてくれてサンクス
自分がだけが使うわけではないから、DynamicDNS登録もcgiもパスかな。
素直に診断君とか、適当な鯖にUDP送って取得することにする
どもでしたー

213 ：デフォルトの名無しさん：2009/08/02(日) 16:53:14

>>206
おそらく以下の記事にある「TCPチェックサムオフロード」の事を
>>200は言っているのだと思う。

FreeBSD 10ギガビットネットワーク高速通信の秘密(2008/10/29)
　[3] ハードウェアオフロードによる処理の高速化
http://journal.mycom.co.jp/articles/2008/10/29/bsdcon5/002.html

ただしサポートしているのは一部のサーバ向けハイエンドNICだけだったはず(?)だし、
ましてや>>197は「組み込み向けネットワークドライバ」と明記しているから、
>>200の言う「いまどき」が何を(or いつの時代)を指しているのかよくワカランwww

214 ：デフォルトの名無しさん：2009/08/02(日) 16:54:48

正常切断でこんなロジックを見かけるけど、これってありなの？
shutdown(soc, SHUT_RDWR);
close(soc);

215 ：デフォルトの名無しさん：2009/08/02(日) 17:37:52

>>213
何年前から来たんだよ。FEの時代は高級品だけだったけど、GbEならオンボだつて蟹だってついてる。>TOE
Windowsのハードウェアのプロパティにチェックサムオフロードの設定あるだろ。
オフロードが効いてるとWiresharkでチェックサムエラーになるから判る。
Linuxは、ドライバ設計が古くてTOE使えない時期が長かったけど、流石に今は対応してたはず。

216 ：デフォルトの名無しさん：2009/08/02(日) 17:44:54

>>214
通信シーケンスに自信がないなら入れておくという程度。
sdの状態的にSHUT_RDWRを指定した時FINハンドシェークが起こるが、
closeをいきなり呼んでも暗黙的にこの処理は行なわれる。
半二重通信でもしない限り明示的なshutdownは必要ない。
ただし、能動通信側が送りっぱなしで突然閉じるようなことをすると、
shutdown無しの場合受動通信側のパケットを無駄に待ってしまったりと
sdが完全に無効になるまで時間が掛かる場合がある。

217 ：デフォルトの名無しさん：2009/08/02(日) 18:03:18

>>216
shutdown(SHUT_WR)
recv() でゼロかエラーが帰ってくるまで待つ。
(どちらも帰って来ない場合もあるのでタイムアウト処理を入れる)
close()

こんな面倒くさい(お行儀の良い)処理をしなくて一方的に切断しても特に
問題ないって事ですか？

218 ：デフォルトの名無しさん：2009/08/02(日) 18:26:47

>>215
>Linuxは、ドライバ設計が古くてTOE使えない時期が長かったけど、流石に今は対応してたはず。
いやデスクトップはいいんだけど、>>197の言う「組み込み向けLinuxボード」でも対応してますか？
>>206の質問にある、(チェックサムオフロードをサポートした)ハード(ボード)にも答えて下さいませ。
あなたは>>200のレスで、>>197に対して「いまどき」と発言しているんですが........。
一般的な事実(独り言)としては正しいのかもしれないけど、質問に対する返答になってない気がします。

219 ：デフォルトの名無しさん：2009/08/02(日) 18:52:09

犬廚はウィンドウズのドライバの詳細項目なんてチェックしないと思うけどな。
TOEってちゃんと動くか？　動かない条件のほうが多いと思うよ。

220 ：デフォルトの名無しさん：2009/08/02(日) 19:29:20

>>219
>TOEってちゃんと動くか？　動かない条件のほうが多いと思うよ。

いや、>>215の住む世界だと、Linux/WindowsともGbEでさえあれば、
TOEが動くのが今時は当然な事らしい....。

221 ：デフォルトの名無しさん：2009/08/02(日) 20:00:40

>>218
話をややこしくして済まないんだが、「クロス開発」で
あって別に Linux 向けの組み込みじゃなかったのよ。
ターゲットは OS から俺一人で書いた奴（RISC CPU で
メモリがバンク切り替えな環境）。

でもって開発環境だった Linux をネットワークドライ
バテストの対向ルーチンにしようとしてて、たとえば
UDP パケットを Linux 側で作ってループバックデバイ
ス通して RAW ソケットで読んで自前のドライバのテス
トケースに突っ込んで…ってなことをやってたわけ。

別にハードウェアで計算するならするでいいけどさ、そ
れなら仮想的なループバックデバイスを使う場合はそこ
で計算すべきじゃないかと思うんだ（計算しない理由は
パフォーマンスを稼ぎたいというのが正解で、コンパイ
ルオプションで計算が有効になるようになってたところ
までは調べた）。

因みにちょっと前にあった「NAT 通した時にチェックサ
ムおかしいんだけど…」なんていうバグはこの辺に起因
してる気がする。くわばらくわばら（w

222 ：デフォルトの名無しさん：2009/08/02(日) 20:20:07

>>217
だからぁ、「一般的には問題ない。でも、ある特別なケースでは
問題となるかもしれない」と>>216はレスしている。
その可能性のあるケース(の一部)も>>216でレスされている。
それが>>217に当てはまるかどうかは、>>217が想定してる状況を
明記してくれないと、エスパーでもない限り誰にも返答できないよ。

横レス失礼

223 ：デフォルトの名無しさん：2009/08/02(日) 20:59:17

>>222
>>216 は、
shutdown(SHUT_RDWR)
close()
と
close() #暗黙的にshutdown処理されるので
は同じだと言っている。

であればshutdown()は意味のないことに成る。

だったら、>>217 の処理はしなくて close() でいきなり
ソケットを閉じても問題ないってこと？

TIME_WAITで処理されるのでどんな切り方をしょようと
結局は皆同じってことでよいのかな？？

224 ：デフォルトの名無しさん：2009/08/02(日) 21:23:38

逆に言えばshutdown入れとけばどんな切り方してもいいから入れとけ。

225 ：デフォルトの名無しさん：2009/08/02(日) 21:33:51

鯖が迷惑するとか考えないのかな。
IPBANされるぞｗ

226 ：デフォルトの名無しさん：2009/08/02(日) 21:42:11

>>224
(ﾟ◇ﾟ)ゞﾗｼﾞｬ -
でも、shutdownしたら鯖の電源が落ちました～

227 ：デフォルトの名無しさん：2009/08/02(日) 21:53:59

鯖が先に切るのか、クライアント側が先に切るのか、
実際はプロトコルによって変わるとしか言えない。
APIの呼び出し手順みたいな単純な話には置き換えられない。

228 ：デフォルトの名無しさん：2009/08/02(日) 22:01:16

組み込みでもチェックサム生成ぐらいの機能なら
ハードウェアに用意してある場合が多い。
もっともエラータで使えなかったりするが。＞microchipのやつ

229 ：222：2009/08/02(日) 22:17:58

>>223
だから、「一般的」には

>だったら、>>217 の処理はしなくて close() でいきなり
>ソケットを閉じても問題ないってこと？

で問題ないと(>>216の先頭に)書いてあります。

>TIME_WAITで処理されるのでどんな切り方をしょようと
>結局は皆同じってことでよいのかな？？

これも、「一般的」には同じと考えてかまいません。

でもね、数百、数千台のクライアントの相手をしなければならない
サーバ環境を想定してみてください。大量に残ってしまった
(カーネル空間内の)TIME_WAIT待ち状態が、システム性能に
深刻な悪影響を与えかねないという事は分かってもらえますか？

もしもそのようなシビアな状況を想定しているのであれば、
(>>216にある「送りっぱなしで突然閉じる」ようなことをせずに)
きちんと手順をふんでTCPコネクションを解法するよう実装すべきです。
でも、>>217,223の想定している状況がどれほどシビアなのかは
本人にしか知り得ないから、誰にも返答できないと>>222でレスしました。

230 ：デフォルトの名無しさん：2009/08/02(日) 22:33:24

>>229
＞サーバ環境を想定してみてください。大量に残ってしまった
＞(カーネル空間内の)TIME_WAIT待ち状態が、システム性能に
＞深刻な悪影響を与えかねないという事は分かってもらえますか？

どんな切り方をしようが先にshutdown()した方にTIME_WAIT状態の
セッションが2MSLは残るんじゃないの？

231 ：222：2009/08/02(日) 22:51:27

>>230
失礼、>>229内にあるTIME_WAITは誤りで、FIN_WAITに訂正します。
(>>216にも、きちんと「FINハンドシェークが...」と書いてありました)

232 ：デフォルトの名無しさん：2009/08/02(日) 23:16:01

>>231
FIN_WAITって鯖側のソケットをclose()しても残ったままになるの？

233 ：222：2009/08/02(日) 23:19:47

>>232
TCPの状態遷移図を(RFCなどで)確認してみてください。

234 ：デフォルトの名無しさん：2009/08/02(日) 23:35:32

えーと、TCP/IP って双方向通信だって事忘れてない?

世の中には一方通行通信で良い場合もあるし、一方通行
で構わないタイミング（たとえば、片方は言いたいこと
を全部言い終わったとか）もある。shutdown() で片方
閉じるってのは元々そういう用途だよ。

235 ：デフォルトの名無しさん：2009/08/02(日) 23:39:05

>>233
RFC見ましたがソケット関数とtcp状態遷移の関係がわからない。。
首吊って人生やりなおしてきます。orz

236 ：デフォルトの名無しさん：2009/08/03(月) 00:15:25

RAWソケットで実際につくってみたらいい

237 ：デフォルトの名無しさん：2009/08/03(月) 00:25:55

>>235
よく見掛ける状態遷移図は参考程度にしといた方がいいっ
てスティーブンスも言ってたんだけど。

http://pfsense.org/~cmb/diagrams/tcpStateDiagram1.gif

たとえば↑で斜体になってるのがアプリが呼び出すメソッ
ドと思えばいい。んでもって矢印が状態遷移だけど、
A/B というのは「A が発生したら B を実施して遷移す
る」の意味。「Close/FIN」はアプリが close() したら
FIN を送出して状態遷移。

そして TCP/IP は双方が established 状態になったら
サーバ／クライアントなんていう区別は無くなるんだよ
（そもそも、双方同時に Active open してもコネクショ
ンが張れるように設計されてる）。

ESTABLISHED から下に遷移している左側がアプリによる
close() の遷移で、右側がその応答である FIN を受け
取ったときの遷移。

双方同時に close() したらどうなるかとか考えてみる
といいよ。

238 ：デフォルトの名無しさん：2009/08/03(月) 00:30:39

おっと、書き忘れてた。

CLOSE_WAIT ってのは「FIN は来たからアプリの
close() 待ちだな」っていう状態で、この時まだ送信で
きる状態。

FIN_WAIT ってのは「アプリは close() したから FIN
待ちだな」っていう状態で、この時まだ受信出来る状態。

239 ：222：2009/08/03(月) 00:43:00

>>235
文書 "RFC 739" 内の図 "Figure 6. TCP Connection State Diagram" は
参照されていると思います。(もし見ていなければ開いてください)

この図の中央に状態 [ESTAB(コネクション確立中)] があります。
この状態でソケットから事象 "CLOSE" を受け付けると、
(TCPスタックは)IPスタック(=クライアント)へ事象 "snd FIN(FINパケットの送信)" を要求し、
(図の左下側にある)状態 [FIN WAIT-1(コネクション解放待ち(1)] へ遷移します。

ここでソケットからの事象 "CLOSE" は、実際にはshutdownかもしれませんし、
(>>216で「closeをいきなり呼んでも暗黙的にこの処理は行なわれる」とあるように)
いきなりのcloseかもしれないし、あるいは(プロセスのexitに伴う)カーネル内部の
close操作かもしれません。そこは実装に依存するのでRFCでは抽象的に記述されています。

で、状態 [FIN WAIT-1(コネクション解放待ち(1)] においては、IPスタック(=クライアント)から
事象 "rcv ACK of FIN(FINに対するACKパケットを受信)"、
あるいは事象 "rcv FIN(FINパケット受信)" を受け付けない限り、
(永遠に)次の状態へは進めない(遷移できない)ことが確認できるのではないかと思います。
これが「(質問>>232にある)鯖側のソケットをclose()しても残ったまま」になる状況(の一例)です。

眠いんで、今晩はこれで落ちます。

240 ：デフォルトの名無しさん：2009/08/03(月) 00:43:16

>>237-238
ｱﾘｶﾞﾄﾝ
でも、その図の何処にもshutdown()が出ていない (´；ω；`)
あの世へ逝ってスティーブンス先生に教えてもらいます。 orz

241 ：デフォルトの名無しさん：2009/08/03(月) 00:51:21

>>239
＞(永遠に)次の状態へは進めない(遷移できない)ことが確認できるのではないかと思います

タイムアウトは実装しているだろうから永遠にって事はないでしょ。
１０分くらい放置プレイされるらしいけど。

242 ：デフォルトの名無しさん：2009/08/03(月) 01:02:45

>>237
その図でもshutdownの各パラメータとの対応とrecv()がゼロを返す
タイミングとかはわからんな。ある程度は想像付くけどね。

でも、そんな遷移図わからなくてもTCP/IPプログラムの作れて
しまうソッケットって素敵。

243 ：デフォルトの名無しさん：2009/08/03(月) 01:23:59

TCP/IP は双方向だから、こっち→あっちとあっち→こっ
ちの二つのデータの流れがあって、そのどちらも

「SYN, データ列、FIN」

の順序になってる。SYN の前や FIN の後にデータは存
在しない。

SHUT_WR は「もう書くことありません」だから、FIN の
送出だよ（で、FIN_WAIT）。

SHUT_RD は「もう読みたくありません」だけど、あっち
には関係無い話でせいぜいこっち側が受信バッファを解
放する位の事しか出来ない（もちろん、アプリ側にもデー
タは来なくなる）。

TCP だとこんな感じだけど、別プロトコルだとまた違っ
た動作が割り振られてる場合もあるよ。

244 ：デフォルトの名無しさん：2009/08/03(月) 01:35:26

>>241
> タイムアウトは実装しているだろうから永遠にって事はないでしょ。
> １０分くらい放置プレイされるらしいけど。

現実的な問題からそういう実装はあるかもしれないけど、
TCP/IP の規格にそんな話は出てこないよ。

TCP/IP はあくまで信頼性のあるコネクションを提供す
るのが目的だから、たとえば ESTABLISHED 状態でたま
たま双方が最後に送出したデータの ACK を受け取った
まま三日間無通信だったとしても「突然切っていい」な
んて話はないよ（突然切った瞬間にあっちが何か喋るか
もしれない）。

245 ：デフォルトの名無しさん：2009/08/03(月) 01:57:55

TCPの上の層がどうこうって話？

246 ：デフォルトの名無しさん：2009/08/03(月) 07:05:39

>>228
>>208

247 ：デフォルトの名無しさん：2009/08/03(月) 07:07:17

>>244
ESTABLISHED で勝手にタイムアウト切断するのは鬼畜だけど
FIN_WAITでのタイムアウトは良いんじゃね？
どうせ一時的な状態だし。

248 ：デフォルトの名無しさん：2009/08/03(月) 08:16:04

>>247
まず、SHUT_WR の状態では切断出来ないよね。向うから
のデータはまだ到着する可能性があるし、アプリだって
read() するかもしれない。

次に SHUT_RDWR の場合だけど、これも切断できない。

たとえば FIN_WAIT の変わりに TIME_WAIT 状態に入っ
たとすると、向うからのデータは破棄されるから向うは
ずっと再送処理を行う事になる。

FIN_WAIT の変わりに CLOSED 状態に入ったとすると、
向うからのデータに対して RST が送出されるからコネ
クションが切断されてしまう（正常系と動きが異なって
しまう）。それに本来入るべき TIME_WAIT に入らない
というのは、TIME_WAIT によって慎重に取り除かれてい
た「シーケンス番号重複問題」が顔を出すことにもなる
よ。

ひょっとしたらもう少し新しい RFC では話が違うのか
もしれないけど、俺が実装した頃の話の理解ではこんな
感じ。

249 ：デフォルトの名無しさん：2009/08/03(月) 08:38:50

ああ、それから FIN_WAIT_1 に入ったって事は FIN を
送ったんだから、その FIN に対する ACK が来るまで
FIN を再送するんだよ。でないと向うに「全部受け取っ
たよ」っていう通知が届いた事が確認出来ないから。

そして（またもや FIN が到着せずに）FIN_WAIT_2 に入っ
たって事は向うがこっちからの ACK を待ってる可能性
があるから、やっぱり向うからの最終データに対する
ACK を再送することになるよね。

250 ：デフォルトの名無しさん：2009/08/03(月) 08:56:14

>>249
> でないと向うに「全部受け取ったよ」っていう通知が
> 届いた事が確認出来ない

あー、これ逆だ。「全部送り終わったよ」の通知を向う
が受けた事の確認だね。

251 ：デフォルトの名無しさん：2009/08/03(月) 10:27:36

裏にDBが絡んでたりとかして、大量のデータを用意するのに時間がかかる鯖が居て、そいつにデータ用意させるリクエストしといて、勝手にSHUT_WRで斬りまくるのは、礼儀に反しそうだｗｗｗ
まあhost_denyされても文句は言えないな。

252 ：デフォルトの名無しさん：2009/08/03(月) 10:31:54

SHUT_WR は FIN が届くからそれでクエリキャンセルす
れば無問題。

253 ：デフォルトの名無しさん：2009/08/03(月) 10:33:36

無問題じゃなくて正しい動作か。クエリ送信し終わって
送信端 close() 状態だね。

254 ：デフォルトの名無しさん：2009/08/03(月) 17:14:31

acceptってどういう処理になるの？
シーケンス番号で区別？

255 ：デフォルトの名無しさん：2009/08/03(月) 18:24:04

あ、相手先のIPとポート番号で区別できるね。
むう・・

256 ：デフォルトの名無しさん：2009/08/03(月) 19:12:48

シーケンス番号って32bitしかないけど衝突とかしないのかな
接続ごとにずらすから、しても問題ないのかな

257 ：デフォルトの名無しさん：2009/08/03(月) 19:14:58

うあ、ハッシュ値で管理とか書いてあるな
頭いいな

258 ：デフォルトの名無しさん：2009/08/03(月) 22:43:36

>>253
SHUT_WRしたらrecv()でのゼロを待つんじゃないのか？
そのrecv()のデータは闇に葬られるが。

259 ：デフォルトの名無しさん：2009/08/03(月) 23:01:59

簡易telnet鯖を実装したのですが、クライアントから来る
IAC+2バイトと0(nop)は応答する気がなかったら
無視しちゃっても問題ないですよね？
一応teratermから使えてるみたいなのでいいや。
RFCのtelnetオプション追うの疲れた。

260 ：デフォルトの名無しさん：2009/08/03(月) 23:14:36

>>254
>>255
巷ではよくセッションの区別は

「ローカルアドレス+ローカルポート+リモートアドレス+リモートポート」

だと言われてますが、スティーブンス本をよ～く読むと
これに加えて「ローカル NIC」っていうのが付きます。

たとえば NIC が二枚挿さってるモバイル PC で、PPP
で割り当ててもらったローカルアドレスが（運悪く）両
方とも同じだった、といった状態が考えられるからです。

261 ：デフォルトの名無しさん：2009/08/03(月) 23:20:39

>>258
手前側で SHUT_WR すると向こう側に FIN が送られます
が、向うからこちらへのデータ送信に影響は無いですよ。
TCP より上のレイヤで「FIN が来たらコネクションクロー
ズ」という約束ごとでも無い限りは。

262 ：デフォルトの名無しさん：2009/08/04(火) 08:05:17

reuseしとけ。

263 ：デフォルトの名無しさん：2009/08/04(火) 17:16:31

AI_ADDRCONFIG フラグってなんのために存在すんの？
これ要らない子じゃね？

264 ：デフォルトの名無しさん：2009/08/04(火) 21:26:39

要る。V4のネームサーバもAAAAレコードを持っている。逆も。

265 ：デフォルトの名無しさん：2009/08/05(水) 21:36:26

IPv6とか邪魔だよな。

266 ：デフォルトの名無しさん：2009/08/06(木) 12:14:24

でっていう

267 ：デフォルトの名無しさん：2009/08/06(木) 12:31:17

もう残り少ないぞ
ttp://www.iana.org/assignments/ipv4-address-space/

268 ：デフォルトの名無しさん：2009/08/06(木) 12:39:00

法人がみんなNGNに行けばいいんだよ

269 ：デフォルトの名無しさん：2009/08/06(木) 12:59:50

中がv4のままなら外がどうなろうとどうでもいい

270 ：デフォルトの名無しさん：2009/08/06(木) 15:02:36

UDPのプログラムでSIGPIPEとか発生することある？
発生条件が想像できないんだけど

271 ：デフォルトの名無しさん：2009/08/06(木) 15:54:31

>>270
実装にもよるんだろうけど, 書き込み方向が shutdown された
socket に書けば SIGPIPE になるよ.

272 ：デフォルトの名無しさん：2009/08/06(木) 19:14:01

>>271
UDPでそれって難しくね？
実装読んだわけじゃないから想像だけど。

273 ：デフォルトの名無しさん：2009/08/06(木) 19:45:43

>>272
Unix 系の実装だと SIGPIPE はソケットが扱ってるプロトコルの処理に
ディスパッチする前に判定されるので, shutdown すれば起きるよ
shutdown(s, SHUT_WR);
sendto(s, ....);
まぁ, ふつうやらんわな………

274 ：デフォルトの名無しさん：2009/08/06(木) 20:38:46

>>273
あ、なーる

275 ：デフォルトの名無しさん：2009/08/09(日) 16:04:05

アナルマン

276 ：デフォルトの名無しさん：2009/08/09(日) 19:14:27

新参の質問ですみません。

Linuxでソケットを使って簡単なプログラムを書いて
ファイル(6KB)転送をしてみたんですが、

サーバーとクライアントのローカルネットワーク内で直接やり取りすると、
途切れることなく到着するのですが、

インターネット経由だと、30%程度の確率で4242バイトで区切られてしまいます。
これって、何が原因なんでしょうか？どうか教えてください。

277 ：デフォルトの名無しさん：2009/08/09(日) 19:34:39

>>276
たぶんインターネット経路の途中にあるルータで
IPパケットが分割されたのが原因だと思います。
もしそうであれば、いたって普通の現象です。
対策については、まずは、このスレの>>72の質問から始まった
一連のレスをじっくり読んでみてください。

278 ：デフォルトの名無しさん：2009/08/09(日) 20:22:11

TCPでしょ。メッセージ境界は保証されない。

279 ：276：2009/08/09(日) 23:46:12

ありがとうございます。

やっぱり途中のルーターなんですね・・・。

しかもレスを読むと、
全パターンの区切り方を想定してバッファやスタックを作るのが対策・・・。
最低どこまでのサイズで区切られるか、試さないといけませんね・・・。
多分1400バイトが安全圏かなぁ・・・。

まぁ、4242バイトに近いパケットを調べたところ、一個だけ該当するものがありまして
どうやら、FDDIのパケット(4500バイト前後)の大きさで区切られているようです。

280 ：デフォルトの名無しさん：2009/08/09(日) 23:59:58

>>279
メッセージサイズ決まってる(固定長)のなら、そのサイズ読み込めばいいし、
決まってないのならメッセージヘッダの中に自分のサイズを含めればいい。

281 ：デフォルトの名無しさん：2009/08/10(月) 00:28:16

>多分1400バイトが安全圏かなぁ・・・。

どうして他の人の言うこと聞かないんだろ。
まともなコードなら、1byte以上全ての可能性に対処すべきなのに。

282 ：デフォルトの名無しさん：2009/08/10(月) 00:57:42

>>279
>多分1400バイトが安全圏かなぁ・・・。

>>278がレスしているように、TCPではメッセージ境界は保証されません。
いわゆるUNIXのパイプと同じ概念で、データの最小単位は1byteでしかないんです。
(だからTCPは「バイトストリーム指向」であると呼ばれることがあります。反意語は「レコード指向」)
言い換えると、理論的には最悪の場合1byte単位でソケットにデータが届くことがあり、
そのケースも想定して実装する必要があります。1400byteなんて安全圏はどこにも存在しません。

もし通信プロセスの実装が同期I/O方式であるなら、>>115の方法を使うのが最も楽です。
そうでないなら(非同期I/O方式であるなら)、推測されたように複雑なFIFO制御が求められます。

そんな設計が苦痛に感じられ、なおかつ(>>279が)アプリケーション層のプロトコル定義を
決定できる立場にあるのだとしたら、専用の通信ライブラリの利用を提案します。
(そのような通信ライブラリのことを「ミドルウェア」と呼ぶことがあります。)

(長いので続く)

283 ：282：2009/08/10(月) 01:10:06

(>>282の続き)

たとえば、Linux上でC/C++を使われるのなら、ONC/RPC(旧名でSunRPCとも呼ばれる)をお勧めします。
いわゆるRPC(Remote Procedure Call)と呼ばれるミドルウェアであり、OSI参照モデルであれば
セッション層からプレゼンテーション層までの範囲に相当するサービスを提供しています。

最も単純な実装の場合、XDR(External Data Representation)と呼ばれる言語でユーザ関数を定義した後、
クライアント側アプリケーションではサーバIPアドレスの指定とユーザ定義関数のコールを実装するだけ、
サーバ側アプリケーションではコールされる(C言語の)ユーザ関数定義を実装するだけで、
あとはONC/RPCシステムにおまかせすることができます。(ONC/RPCシステムのセットアップは必要です)

メッセージ境界処理はもちろんのこと、UNIXソケット実装の差異(Linux/xxxBSD/Solaris/MacOSX等)や
CPUアーキテクチャの差異(Intel/PowerPC/ARM/SPARC等)までも吸収してくれます。
また、非同期コールにも当然対応しています。([例] サーバ：selectで実装、クライアント；GTKで実装)

ただし、ONC/RPCの発想に慣れるまでは、最初の壁がきついかもしれません。
詳細については書籍「RPCプログラミング株式会社アスキー」を参考にしてください。
また、英語ばかりですが、事前にmanでrpcgenコマンド(XDR言語-->C言語自動生成ツール)を
調べてみたり、RPCプロトコルの仕様書(RFC 1831)を読んでおくのもいいかもしれません。
大半のUNIXでは、C言語開発メタパッケージがインストールさえしてあれば、ONC/RPCは即利用可能です。
ONC/RPCは以前に何度か利用しているので、何か質問あればどーぞ。

284 ：デフォルトの名無しさん：2009/08/10(月) 01:15:36

単なるメッセージの送受信にRPC持ち出すのは騒ぎすぎ。
俺が技術責任者なら却下する。

285 ：282：2009/08/10(月) 01:58:58

>>284
ONC/RPCなんてUNIXで標準に付属してる「単なる道具」にすぎないよ。何を怖がってるの？
ただで使えるものは使ったほうがイイと思う。モッタイナイ！！
最初の壁を突破できれば、後は楽々で生産性は向上するわバグも減るわ移植性も確保できる。
本人にとっても習得した技術は他のプロジェクトへ移っても活用できるし。(UNIX限定だけどね)

あとONC/RPCをOMG/CORBAやMicrosoft DCOMみたいな分散オブジェクト技術と
ごちゃまぜにして理解していないかい？
それらと比較すると、ONC/RPCなんて非常にシンプルなシステムだよ。
Web Serviceであれば、SOAPとXML-RPCの差であると言い切ってもいいと思う。(分かるかな？)

まあ、(メッセージの送受信じゃなくて)単なるファイル転送くらいならRPCは大げさかも。
ただし、それを判断するのは>>279のプロジェクトの内容しだいだよ。却下は即断すぎる。

286 ：デフォルトの名無しさん：2009/08/10(月) 02:17:14

>>285
いや、それを言うなら単にソケット開いて、メッセージ送受信するだけですむのに。
(さらに、ほぼそのままWindowsに持っていっても動くし、他の言語からも使用しやすい)

Web-Serviceで言えばRest風サービスですむのに(なんなら、PHPで動的テキスト返す
くらいのものでもいい)、何でSOAPとかXML-RPCとか持ち出すの？っていうこと。

287 ：デフォルトの名無しさん：2009/08/10(月) 02:23:50

ファイル転送したいだけでしょ？
ftp使えば？
生産性とか移植性とかそんなもんすら関係ないし

288 ：デフォルトの名無しさん：2009/08/10(月) 02:26:04

ファイル転送なら、httpの方がいろいろ楽な気が。

289 ：282：2009/08/10(月) 03:18:52

>>286
>いや、それを言うなら単にソケット開いて、メッセージ送受信するだけですむのに。

それが通用するのは同期式I/Oの場合だけで、そのケースについては
>>282で「>>115の方法を使うのが最も楽」と書いてあるよ。よく読んでね。

>(さらに、ほぼそのままWindowsに持っていっても動くし、他の言語からも使用しやすい)

まさかCygwinとかPOSIXサービスが前提とか言い出すんじゃないだろうね？
WinSockが名前はソケットでもUNIXソケットとはまるで実装が違うのは知っているはずだし。
何を指して「ほぼそのままWindowsに持っていっても動く」と言っているの？教えてくださいませ。

>Web-Serviceで言えばRest風サービスですむのに(なんなら、PHPで動的テキスト返す
>くらいのものでもいい)、何でSOAPとかXML-RPCとか持ち出すの？っていうこと。

RESTとXML-RPCはXML前提か否かが違うくらいで、複雑さは同レベルだよ。
しかも、もしXMLの技術を持っていて、なおかつメッセージ定義が複雑になっていった場合、
(サービスとREST APIの対応付けを実現しなければいけないという強い制約があるRESTよりも)
メッセージ型が柔軟に(XMLで定義できる)XML-RPCのほうが設計は容易であるというのが常識だし。
SOAPはXML+HTTPベースの分散オブジェクト技術だから言わずもがな。
結論として複雑さの比較は、XML-RPC = REST << SOAP になる。反論あるかい？
信じられないレスなんだけど、本当にREST/XML-RPC/SOAPを使ったことがあるの？

290 ：282：2009/08/10(月) 03:25:13

>>287
>ファイル転送したいだけでしょ？

だからファイル転送のレベルかどうかは>>279しだいだと(>>285で)書いたんだが。
レス読んでいるかい？>>279からレスが来ないかぎり、誰にも判断できないはずだよ。

>ftp使えば？

C言語に(バグの枯れた)デファクトなFTPライブラリってあったっけ？自分は知らない。あれば教えて。
あるいは自分でFTPプロトコルをC言語で実装するということ？本末転倒じゃないか。
それともC言語からftpコマンドを起動するっていうことかな？OK、それなら納得する。
でもそれはネットワークプログラミングから外れる(スレ違いな)提案じゃないのかな？

291 ：282：2009/08/10(月) 03:40:31

>>290のレスに自己レス。

>C言語に(バグの枯れた)デファクトなFTPライブラリってあったっけ？自分は知らない。あれば教えて。
>あるいは自分でFTPプロトコルをC言語で実装するということ？本末転倒じゃないか。
>それともC言語からftpコマンドを起動するっていうことかな？OK、それなら納得する。
>でもそれはネットワークプログラミングから外れる(スレ違いな)提案じゃないのかな？

Debianくらいのディストリになれば、C言語で書かれたFTPライブラリパッケージはあっても
おかしくない気がする。あと、GNOME前提でよければ、確かGNOME APIの中に
FTP/HTTP(WebDAV)を扱うライブラリ関数はあったはず。だから、この段落は取り消します。

292 ：デフォルトの名無しさん：2009/08/10(月) 05:49:15

> >いや、それを言うなら単にソケット開いて、メッセージ送受信するだけですむのに。
>
> それが通用するのは同期式I/Oの場合だけで
非同期でも問題ないけど。

293 ：デフォルトの名無しさん：2009/08/10(月) 05:53:09

なんか投げやりな質問で悪いけど、
linuxでONC/RPCを使う方法教えてくれ。
サンプルコード的なの。

294 ：デフォルトの名無しさん：2009/08/10(月) 08:50:11

ONC/RPCは鶏を割くに焉んぞ牛刀を用いんって奴だな。
インターフェース書くも実運用もの面倒くさい。 >>280でFAだろ。

295 ：276=279：2009/08/10(月) 11:59:53

えーと、なんといいますか、一騒ぎ起きていますね、すみません。
UNIX・LinuxでC言語チャットサーバーを作ることを想定してます。

ログメッセージ以外のデータの長さは固定長で決まっているので、
ほぼ固定長のデータをやり取りする事になりますね。

ちなみに、クライアントはFlash(AS3.0)です。
Flashの扱いは慣れているのでこちらについては大丈夫です。

今、ONC/RPCについて調べてみてます。

296 ：デフォルトの名無しさん：2009/08/10(月) 21:47:34

そろそろ .NET Remoting の登場ですか？

297 ：デフォルトの名無しさん：2009/08/11(火) 03:18:13

ONC/RPCなんて今時使ってるのか？w

298 ：デフォルトの名無しさん：2009/08/11(火) 04:17:59

Google様にRPCしたい

299 ：デフォルトの名無しさん：2009/08/11(火) 05:38:29

TCPのMSS(最大セグメントサイズ)はどれぐらいまで小さくできるでしょうか？
一度にやってくるパケット量を制限したいので。
何かのRFCに載ってませんか？

300 ：デフォルトの名無しさん：2009/08/11(火) 09:22:12

TCPヘッダの最大長程度までは小さくできるとは思うが,
mss だけ小さくしても意味ないと思うぞ

受信バッファサイズとか, その他のパラメータも関わってるんだから…

301 ：デフォルトの名無しさん：2009/08/11(火) 18:54:03

AI_ADDRCONFIG フラグってなんのために存在すんの？
これ付け忘れて困るシチュエーションが思いつかない

302 ：デフォルトの名無しさん：2009/08/11(火) 19:06:21

>>301
v6使ってないんだったら意味ねぇと思う
つか, document 読め

303 ：282：2009/08/11(火) 22:24:58

>>295
>ちなみに、クライアントはFlash(AS3.0)です。

クライアントはFlashですか....。でしたらONC/RPCの提案は取り下げます。
C言語とActionScriptとの(SwingやJNIのような)バインディング方法や
完成したライブラリをプラグインとして配布する方法を考えないといけないですから。

>>293
>linuxでONC/RPCを使う方法教えてくれ。

オンラインであれば筑波大の講義資料(？)の中に簡潔な解説がありました。
http://www.coins.tsukuba.ac.jp/~yas/coins/dsys-1998/1999-01-19/index.html

あと以下の書籍にも第16章で(ONC/RPCの旧名である)SunRPCが解説されています。
この書籍は(>>3でVol.1が紹介されているように)所蔵されている図書館/書店が多いでしょう。

UNIXネットワークプログラミング〈Vol.2〉IPC:プロセス間通信
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712571

>>297
>ONC/RPCなんて今時使ってるのか？w

正直な話、使っている人はほとんどいないでしょう。ただ、(>>285で書いたように)
用途や環境がハマれば、今でも有効な「道具」ですから、このスレで紹介してみました。

最後に、GoogleによるONC/RPCの「車輪の再発明」であるProtocol Bufferを紹介します。
　http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/menu.html
ONC/RPCと比較すると、C++/Java/Pythonバインディングがある点を除けば、特徴は同一です。
新しいモノ好きな方にはお勧めかもしれません。

304 ：デフォルトの名無しさん：2009/08/11(火) 22:32:22

「車輪の再発明」とかまだ使ってるんだ。恥ずかしくない?

305 ：デフォルトの名無しさん：2009/08/11(火) 22:51:56

税金を使って研究している人にはよくあること

306 ：デフォルトの名無しさん：2009/08/11(火) 22:58:47

初心者教えるのにかこつけて自分の趣味押し付けるのはやめようや。

307 ：デフォルトの名無しさん：2009/08/11(火) 23:15:39

>>302
100回くらい読んだよ。読んでもわからん。
実験もしたけど、あってもなくてもIPv6のIPアドレスがあればIPv6の方引けるし
なければIPv4のが引けるし。
とりあえず保険でつけとけって感じでいいのか？

308 ：デフォルトの名無しさん：2009/08/11(火) 23:17:53

>>303
よくわからんのだけど、実装がコンパクトでオーバーヘッドがほとんどないなら
RPC使ってみたい

309 ：282：2009/08/12(水) 00:54:25

いいかげん、このスレの主旨である「ソケット中心」からは外れていますし、
>>276の質問に対する結論も(>>303)で出たので、ONC/RPCに関する話題は
これで終わりにします。長々としたスレ汚し、失礼しました>>all

310 ：デフォルトの名無しさん：2009/08/12(水) 02:02:33

誰も相手にしてないから良いよ。

311 ：デフォルトの名無しさん：2009/08/12(水) 13:52:01

TCPでアクティブクローズしてTIME-WAIT状態になったら、
あとは同じIPアドレスとポートの組のパケットを一定期間受け流すだけだから、
実際の実装ではTCBから切り離してTIME-WAITリストみたいなもので管理すれば、
最大同時接続数に影響しないと考えていいでしょうか？

312 ：デフォルトの名無しさん：2009/08/12(水) 14:02:00

>>311
それは管理されてるから対象
同時接続数は同時管理数と読みかえれ

313 ：デフォルトの名無しさん：2009/08/12(水) 14:08:31

そうですね。
言い方を変えればTIME-WAIT用の限定的なTCBに切り替えるという感じです。
フル機能のTCB領域に限りがあるので、
TIME-WAITで使ってしまうと厳しいのです。

314 ：デフォルトの名無しさん：2009/08/12(水) 14:51:04

TIME-WAIT専用TCBに必要だと思われる情報
MSL_timeout 1byte
相手IPaddr 4byte
相手Port 2byte
合計7バイト

MSL_timeout==0なら空きとみなす
相手MACはパケット受け取った時に入れ替える
SND.NXTも同様
RCV.NXTはFINがきたら+1して入れ替える

315 ：デフォルトの名無しさん：2009/08/12(水) 16:57:03

>>314
>>260 で示したセッションを区別できないといけない。
あちら側のアドレスとポートが同一でも、こちら側のポー
トが違えばコネクションは生成される。

316 ：デフォルトの名無しさん：2009/08/12(水) 17:00:52

>>314
RFC1122も読んでおくといいです。

http://www2s.biglobe.ne.jp/~hig/tcpip/HostReq_Comm02.html#HREQCOM_4_2_2_13

> コネクションが能動的にクローズされた場合、TCP は
> 2×MSL (最大セグメント生存時間) の時間だけ
> TIME-WAIT 状態に留まらなければならない (MUST)。
> しかし TCPは、以下の条件下で TIME-WAIT 状態から
> 直接コネクションを再オープンして、リモート TCP
> からの新しい SYN を受け入れてもよい (MAY)。
>
> 1. 前のコネクションの化身で使用された最も大きい
> シーケンス番号よりも大きい初期シーケンス番号を、
> 新しいコネクションに対して割り当てる。
>
> 2. もし SYN が古い重複であることが判明したら
> TIME-WAIT 状態に戻る。

317 ：デフォルトの名無しさん：2009/08/12(水) 17:15:58

>>316
RFC1122もさらっとですが読みました
もしTIME-WAITでSYNがきたら放置する方向でやろうと思ってます
(アクティブオープンを、切断した同一ポートで開こうとする状況は
ほとんどありえない感じなので)

318 ：デフォルトの名無しさん：2009/08/12(水) 17:18:44

>>315
あー、そうか
ローカルポートの情報も持ってないとだめですね

319 ：デフォルトの名無しさん：2009/08/12(水) 18:38:40

>>317
> アクティブオープンを、切断した同一ポートで開こう
> とする状況はほとんどありえない感じ

確かスティーブンス本（Unix Network Programming の
一番古い奴）に half association 指定のオープンの話
があったと思うんだけど、あれってパッシブだけだった?

320 ：デフォルトの名無しさん：2009/08/12(水) 19:00:53

なんちゃってTCP感が否めないな。
ウェブ連中はライトウェイトTCPとか呼びそうだがｗｗｗ

321 ：デフォルトの名無しさん：2009/08/12(水) 19:07:12

はてな民が好きそうだな

322 ：デフォルトの名無しさん：2009/08/13(木) 13:15:21

ｸﾞｸﾞﾙと引っかかるはてな
中身を見てみると内容が無いようのはてなですね
消したけど

323 ：デフォルトの名無しさん：2009/08/13(木) 13:40:10

2000年頃、調べものでググるといっつも引っかかる掲示板があって
いつのまにかその掲示板に入り浸るようになってしまった・・・

324 ：デフォルトの名無しさん：2009/08/14(金) 09:28:33

ONC/RPC最高age

325 ：デフォルトの名無しさん：2009/08/14(金) 10:13:44

ｸﾞｸﾞﾙと引っかかるahoochiebukuro
中身を見てみると内容が無いようのahoochiebukuroですね
消したけど

326 ：デフォルトの名無しさん：2009/08/14(金) 16:04:57

winsocketの日本語リファレンスありますか？

327 ：デフォルトの名無しさん：2009/08/14(金) 16:53:19

ありません。

328 ：デフォルトの名無しさん：2009/08/15(土) 11:05:40

winsock2ってTCP/IPでクライアントやアドレスを複数作ってマルチキャストすることできます？

329 ：デフォルトの名無しさん：2009/08/15(土) 11:46:58

ﾃﾞｷﾏｾﾝ

330 ：デフォルトの名無しさん：2009/08/15(土) 12:05:43

夏だなあ。
上の方にもいたが、TCPでブロードキャストやマルチキャストが無理なんてのは
バカでもわかりそうな事だが。

331 ：デフォルトの名無しさん：2009/08/15(土) 12:47:53

IPv6でも駄目なんか?

332 ：デフォルトの名無しさん：2009/08/15(土) 13:05:29

>>331
TCPの中の人がどんな仕事をしているかを知ってさえいれば、
IPv4/IPv6無関係に　駄　目　だというのは分かるようになるよ。

333 ：デフォルトの名無しさん：2009/08/15(土) 13:11:06

http://www.geocities.jp/katayama_hirofumi_mz/win32/write2ch.htm

334 ：デフォルトの名無しさん：2009/08/15(土) 13:40:23

TCP/IPとUDPを同時に使うことはできますか？
また、UDPで複数同時に受信するにはどうすれば良いっですか？

335 ：デフォルトの名無しさん：2009/08/15(土) 13:49:30

> TCP/IPとUDPを同時に使うことはできますか？
出来ます。
> また、UDPで複数同時に受信するにはどうすれば良いっですか？
普通に受信すれば良いです。

336 ：デフォルトの名無しさん：2009/08/15(土) 13:58:39

>>332
IPv6ってアドレスが多いだけで今まで出来なかった
凄いことができるわけでは無いんだな。
NATあるしv6ｲﾗﾈ

337 ：デフォルトの名無しさん：2009/08/15(土) 14:05:21

>>335
普通に受信とは用意したバッファに全ての接続先からのデータが無造作に収められるということですか？

338 ：デフォルトの名無しさん：2009/08/15(土) 14:43:18

>>332
あるUDPパケットが到着した後、アプリケーションがrecvfromで
受信パケットを取り出さないうちに、次のUPDパケットが到着した場合、
いずれかのパケットが破棄されます。どちら(先着 or 後着)が破棄されるかは
UDP仕様として規定されていません。実装に依存します。
すべてのパケットを確実に受信したければ、TCPを使用しませう。

339 ：デフォルトの名無しさん：2009/08/15(土) 14:56:12

流れ読めないバカ(>>338)も夏の風物詩か?

340 ：デフォルトの名無しさん：2009/08/15(土) 16:18:04

質問責めですみません。複数受信するにはポートを複数つくるというところまでわかりました。
でも送信側からみればどのポートが埋まっていないのかわからないと思うのですが、どういう風に知り得ることができますか？

341 ：デフォルトの名無しさん：2009/08/15(土) 16:22:53

普通は複数受信でもソケットは1個しかつくらんよ

342 ：デフォルトの名無しさん：2009/08/15(土) 16:27:01

>>340
複数受信とは複数のクライアントの接続のことかな？

343 ：デフォルトの名無しさん：2009/08/15(土) 16:47:20

>>342
多分それだと思います。
winsock2の情報が少なくてこのスレが一番の情報源だったりします。ネット接続は必要な機能なわりにちょっとしか使わないし本を買ったりして専門的にやるには持て余してしまう。

344 ：デフォルトの名無しさん：2009/08/15(土) 16:58:01

>>343
>>1 のWinsock FAQくらいは目を通しておこう。

345 ：デフォルトの名無しさん：2009/08/15(土) 17:05:05

キミに必要なのはwinsock2の情報じゃなくて、ネットワークプログラミングの基礎知識だ。
winsock2の情報が少ない事を言い訳にするな。

346 ：デフォルトの名無しさん：2009/08/15(土) 17:14:04

>>343
外注に出した方が安く付くと思うよ。

347 ：デフォルトの名無しさん：2009/08/15(土) 17:56:58

>>346
いや、ぼられるので高くつく

348 ：デフォルトの名無しさん：2009/08/15(土) 17:58:26

>>343を使えるまでに調教する方が高い。

349 ：デフォルトの名無しさん：2009/08/15(土) 18:25:46

>>348
二アリーイコール君達を調教しているおいらは心が折れそうです

350 ：デフォルトの名無しさん：2009/08/15(土) 18:35:51

>>340
> 送信側からみればどのポートが埋まっていないのかわからない

>>260 にあるセッションが区別できれば通信できるように
なってる。

現実世界のハブのポートみたいなのを想像してると勘違
いするかもね。何か良いアナロジーないだろうか。

351 ：デフォルトの名無しさん：2009/08/15(土) 19:38:46

TCPだとlistenで代表電話番号できて, connect要求あるとそこらじゅうの
電話機がなって, 誰かがどれかの受話器を取り上げるのがacceptってな
イメージなんだが, UDPの場合はなぁ………
特定のチャンネルを使ってるトランシーバってイメージでもないしなぁ…

352 ：デフォルトの名無しさん：2009/08/15(土) 19:42:12

銀行と口座番号というのはどうだろうか

銀行がIPアドレス、支店がNIC、開設口座番号がポート

353 ：デフォルトの名無しさん：2009/08/15(土) 19:48:04

集合住宅間を行ったり来たりする郵便
住所がアドレス, 部屋がポート, 差出人の住所その他がrecvfromで受け取るアドレス

354 ：デフォルトの名無しさん：2009/08/15(土) 19:48:55

下手に例を使って理解するよりも、そのまま理解したほうが後々楽。

355 ：デフォルトの名無しさん：2009/08/15(土) 20:12:25

しかも、調教中の回答者も好き勝手言ってるからな。

356 ：デフォルトの名無しさん：2009/08/15(土) 20:26:12

listenが美人なポン引きで、clientが繋いで来ても
決してその美人とやれる分けでもなく。
下ネタでｽﾏﾇ

357 ：デフォルトの名無しさん：2009/08/16(日) 05:58:23

美人ほどrejectされまくるしな。

358 ：デフォルトの名無しさん：2009/08/16(日) 10:20:28

Port 80のリスナーは嫉妬するほど大人気

359 ：デフォルトの名無しさん：2009/08/16(日) 12:35:31

二股どころか、数百数千人相手のですか、さぞかしガバ(ry

360 ：デフォルトの名無しさん：2009/08/16(日) 12:48:25

Port 80嬢は斡旋だけなので

361 ：デフォルトの名無しさん：2009/08/17(月) 10:00:09

>>351
UDPは有能な秘書が全部一人で手紙を受け取ります。
電話ではありません。

362 ：デフォルトの名無しさん：2009/08/17(月) 12:06:28

どんなに優秀でも取りこぼすけどな。郵便屋が途中で捨ててたりもするし。

つまり８０番で客引きしてるアパッチのバックには怖い人が居たりするのねえ。
まあ
１０２４以下のポートで客引きするには権力者の許可が必要だけど。

363 ：デフォルトの名無しさん：2009/08/17(月) 13:01:01

RFC2863 に出てくる
IfAdminStatus と IfOperStatus
ですが、両者の違いがいまいち
判りません。上記RFCにはこれらの
定義が書いてないようなんですが
両者の違いを教えてください。

364 ：デフォルトの名無しさん：2009/08/17(月) 13:35:06

しっかり書いてあると思うんだが。

365 ：デフォルトの名無しさん：2009/08/17(月) 14:09:37

よくUDPはルータ超えできないという発言を見かけますが、
これはどういう意味でしょうか？
大抵のルータはポートマッピング機能とかがあるし、
超えるのに特に支障はないと思うのですが。

366 ：デフォルトの名無しさん：2009/08/17(月) 14:19:07

ユーザにルータの設定をしてもらうよう頼むわけにはいかないでしょう
ユーザはマニュアルなんか読まないんだから
UPnPなりUDPホールなんとかでアプリが自力で通すんなら構わないと思う

367 ：363：2009/08/17(月) 15:19:30

>>364
うぅ最後まで良く見てませんでした。
すみません。

368 ：デフォルトの名無しさん：2009/08/17(月) 17:24:10

ここって、初心者が質問していいとこ？

369 ：デフォルトの名無しさん：2009/08/17(月) 17:45:22

Cの初心者とかプログラミング自体の初心者とか質問の仕方の初心者とかはちょっとあれだけど
ネットワークの初心者ってだけならどうぞ

370 ：デフォルトの名無しさん：2009/08/17(月) 23:26:23

TCP/IPレベルは本読んで恋で終了だけどな。

371 ：デフォルトの名無しさん：2009/08/18(火) 00:16:25

>>366
つまりルータではじかれる設定ということですよね？
だったらUDPに限らずTCPでも同じだと思うのですが。

372 ：デフォルトの名無しさん：2009/08/18(火) 00:27:07

>>371
TCPは状態を持っているので、中から外に出た奴への戻りが明確にわかかる

UDPの場合、状態を持っていないので、中から外へ出た奴の戻りがどれに
対応するか判定できない

実質的には、タイマー管理するかUPnP的にルータ/スイッチをコントロール
するしかない

安全側に倒そう思ったら「UDP を通すな」ってなことになる

373 ：デフォルトの名無しさん：2009/08/18(火) 00:32:45

UDPの場合、ブロードキャスト使うプロトコルも多いから「ルータ越えできない」って
言ってるんじゃないの？
あと、UDPだと間にNATが入ってるとちょっと面倒。

374 ：デフォルトの名無しさん：2009/08/18(火) 00:35:40

>>372
>TCPは状態を持っているので
これはルータがTCPの状態を持っているという意味ですか？
リピータならありえない話ではないですが、解釈がおかしくないですか？
そうでないとしたら意味が判らないし。(UDPでも状態を持てばいい)

375 ：デフォルトの名無しさん：2009/08/18(火) 00:38:17

>>374
もうちょっと勉強してからくるか素直に質問したら？

376 ：デフォルトの名無しさん：2009/08/18(火) 00:43:27

>>375
そう言ってお茶を濁そうとするのは勉強が足りてないってことですよね？
素直に>365で質問してるつもりですが。何か問題でも？

377 ：デフォルトの名無しさん：2009/08/18(火) 00:44:52

>>373
> UDPの場合、ブロードキャスト使うプロトコルも多いから
ちゃんと設定できるルータならディレクティッドブロードキャストは
通すように設定可能

>>373
> これはルータがTCPの状態を持っている
あ、言い方が悪かった
ルータ/レイヤ3スイッチのフィルター機能がTCPの状態を監視してる

> (UDPでも状態を持てばいい)
わざと状態を持たないように設計されているのが UDP

378 ：デフォルトの名無しさん：2009/08/18(火) 00:47:08

>>377
つまりTCPの場合はコネクションを監視することで通すかどうか決めてるわけですね。
UDPだとポートしか情報がないから何が起きてるか判らない、監視しようがないと。

379 ：デフォルトの名無しさん：2009/08/18(火) 00:50:14

>>378
そだよ。
> UDPだとポートしか情報がないから何が起きてるか判らない、監視しようがないと。
監視しようとすると、適当に短いタイマーでここまでは通すか否かを判定するか
こっちから、これを出したからこのポート外から通してねってフィルター機能に
御願いするしかないわけだ

380 ：デフォルトの名無しさん：2009/08/18(火) 00:52:59

>>379
だいぶすっきりしました。
ありがとうございました。

381 ：デフォルトの名無しさん：2009/08/18(火) 01:01:11

>>377
わざわざユーザに設定させるわけにはいかんっていう話じゃなかったっけ？

382 ：デフォルトの名無しさん：2009/08/18(火) 01:08:38

>>377
いや、元々ブロードキャストの話じゃないし…
AHつかえればディレクティッドブロードキャスト通すこともあるだろ?
運用的には………
ってな、意味で >>373 へのレス書いたつもり
誤解を受けたんだったら誤る

383 ：デフォルトの名無しさん：2009/08/18(火) 01:12:41

都市伝説の一種

384 ：デフォルトの名無しさん：2009/08/18(火) 01:18:49

なんかルータとFWとNATがごっちゃになってるが、>>365の本来の質問は家庭用NATルータの話だろ。

UDPもTCPも基本タイマーでセッション管理してるよ。TCPはステートがある分監視、制御に有用な情報が多いだけ。
TCPだって外からSYN(接続)が来ることに関しては、いわゆる「port空け」なきゃ通信できないし、
UDPもDNSの問合せみたいに内→外がトリガとなる1対1の通信ならば何の問題もなく使えるだろ。

問題となるのはUDPの1対多の通信で、これができるかどうかはルータのNATの実装に依存する。
Cone NAT、Restrict NAT、Symmetric NATでググれ。

385 ：デフォルトの名無しさん：2009/08/18(火) 01:28:30

>>384 そうなのか？ NAT のことは何も考えてなかったw

386 ：デフォルトの名無しさん：2009/08/18(火) 02:18:36

単にNAT実装したPGのレベルに寄るけどね。
家庭で使う様なカスルータじゃTCP通すだけで十分で終わりって実装も多いだけ。
組み込みsoc程度じゃそんな程度。

387 ：デフォルトの名無しさん：2009/08/18(火) 03:21:31

いやむしろ、>>365に対して誰かが言った
>UDPはルータ超えできない
という話がそもそも違う(言った奴か>>365が誤解してる)だけだろ。

UDPだろうとTCPだろうと、
(最初に)外からデータを送る分には、いわゆるポート空けをしないと出来ない。

けれど、最初に内から外に向かってリクエストを送り、(外のサーバーが)レスポンスを返す場合に
TCPならばルータがセッション管理しているから、問題なくレスポンスを(最初の)送信元に送れるけど
UDPでは、レスポンスがルータで止められて、クライアントに戻すことが出来ない。

という話が「UDPではルータ(NAT)を超えられない」という言い方にすり変えられてるんじゃないかね。
(多くのルータでは、時間管理等でUDP hole punchingが可能であるというのは置いといて)

388 ：デフォルトの名無しさん：2009/08/18(火) 03:52:41

ルータにポート空けとか関係なくね？
(確かにFWとかNATとかを兼ねてることも多いけど)

389 ：デフォルトの名無しさん：2009/08/18(火) 04:02:24

都市伝説の一種

390 ：デフォルトの名無しさん：2009/08/18(火) 07:07:14

「ルータ」と聞いて、本来のルータを思い浮べる人と、
家庭用のいわゆるブロードバンド・ルータを思い浮べる人と、
レイヤ3スイッチを思い浮べる人では話が合わなくて当然。

本来の意味のルータがUDPを通さなかったら、それは大問題です。

391 ：デフォルトの名無しさん：2009/08/18(火) 07:11:20

ARPはルータ超えできない

392 ：デフォルトの名無しさん：2009/08/18(火) 07:26:45

>>391
そりは(UDPうんぬんじゃなくて)ブロードキャストを利用してるからだろ

393 ：デフォルトの名無しさん：2009/08/18(火) 08:08:02

>>391
IPじゃないものをIPネットワークに流すわけにはいかんだろ

394 ：デフォルトの名無しさん：2009/08/18(火) 08:10:01

インターネット越しのWakeupOnLanはどうやってるん？

395 ：デフォルトの名無しさん：2009/08/18(火) 09:09:41

wakeup on lan のトリガーとなるデータはイーサネットフレーム内のどこにあっても
いいわけだから、ルータで UDP のフォワード先をブロードキャストアドレスにして
おけば問題ないと聞いたことがある

396 ：デフォルトの名無しさん：2009/08/18(火) 09:32:31

>>387
＞UDPでは、レスポンスがルータで止められて、クライアントに戻すことが出来ない。
＞という話が

そんな話は無い。TCPだろうが、UDPだろうが、ポート番号無視しない限りレスポンスが返らないなんてことはない。
ntpとかdnsとかどうすんだよ。

397 ：デフォルトの名無しさん：2009/08/18(火) 09:42:33

>>393
ICMP

398 ：デフォルトの名無しさん：2009/08/18(火) 11:12:07

>>397
IPと同じ層だけど違うネットワークじゃん？

399 ：デフォルトの名無しさん：2009/08/18(火) 11:16:33

ICMP is actually an integral part of IP

400 ：デフォルトの名無しさん：2009/08/18(火) 11:20:19

http://www3.ocn.ne.jp/~tkatu/TCPHeader.html
TCPヘッダについてなんですが
Optionがつくかどうかというのはどこを見ればいいでしょうか？
どこからがデータなのかの判断が付かず困っております。

401 ：デフォルトの名無しさん：2009/08/18(火) 11:31:47

>>400
Data Offset を見ろ。

402 ：デフォルトの名無しさん：2009/08/18(火) 11:34:26

>>401
おっと。こんなところに。さんくす！

403 ：デフォルトの名無しさん：2009/08/18(火) 11:36:42

>>400
最近TCPスタックを実装したばかりの俺が答えてやると、
ずばりData Offsetだ。
Optionがなければ5(5*4オクテット = 20)だ。
SYNなら大抵MSSとかが付いてきて+4で6以上になる。
5未満だったらアウツ。

404 ：デフォルトの名無しさん：2009/08/18(火) 11:37:36

>>403
がんばれ。

405 ：デフォルトの名無しさん：2009/08/18(火) 11:45:25

できました。さんくす。

406 ：デフォルトの名無しさん：2009/08/18(火) 19:49:36

Winsock2でサーバアプリケーションを作っているんですが
すでに使われているポートに対してbindしても関数は成功してしまいます。
（その後の通信には失敗する）
すでに別のアプリケーションがポートを使っている場合にエラー表示させたいのですがどうすればいいのでしょうか？

SvrSock = socket(AF_INET, SOCK_STREAM, 0);
if (SvrSock == INVALID_SOCKET) return false;
addr.sin_family = AF_INET;
addr.sin_port = htons(FSvrPort);
addr.sin_addr.S_un.S_addr = INADDR_ANY;
setsockopt(SvrSock, SOL_SOCKET, SO_REUSEADDR, (const char *)&yes, sizeof(yes));
if (bind( SvrSock, (struct sockaddr *)&addr, sizeof(addr)) != 0) return false;
if (listen(SvrSock, 5) != 0) return false;

407 ：デフォルトの名無しさん：2009/08/18(火) 21:39:52

SO_REUSEADDR のかわりに SO_EXCLUSIVEADDRUSE ではダメですか？

408 ：デフォルトの名無しさん：2009/08/18(火) 21:49:25

>>407
うまくいきました！
ありがとうございました！

409 ：デフォルトの名無しさん：2009/08/18(火) 22:00:54

Winsockでは、SO_REUSEADDRとSO_EXCLUSIVEADDRUSEのどちらも設定しなくても、
LinuxでSO_REUSEADDRしたのと同じ結果になるって書いてあるブログがあるけど。

WinsockでSO_EXCLUSIVEADDRUSEを設定すると、
FIN_WAIT_2 や CLOSE_WAIT の間もEADDRINUSEになるらしい。

ttp://sakanaya.kir.jp/ymnet/diary/fsdiary.cgi?data=20070903

本当かどうかは知りません。

410 ：初心者：2009/08/18(火) 22:06:34

http://www.dotup.org/uploda/www.dotup.org46048.lzh.html
どこが間違っていて文字を送れない(-1が戻ってくる)のか教えてください

411 ：初心者：2009/08/18(火) 22:07:19

↑winsock2です

412 ：デフォルトの名無しさん：2009/08/18(火) 22:26:52

エラー処理しろよ。 connect とか bind とか listen とか accept の戻り値をちゃんとチェックするべし。

413 ：デフォルトの名無しさん：2009/08/18(火) 22:40:29

戻り値はrecv()以外は成功しています。
今もう一度F11連打でやってみたらちゃんと送られました。でもアプリケーションとして実行すると失敗します。

414 ：デフォルトの名無しさん：2009/08/18(火) 22:46:03

recvの戻り値が-1ならWSAGetLastError()してみろ。
n = recv(...);
if (n == -1) {
printf("error : %d\n", WSAGetLastError());
return 1；
}

415 ：デフォルトの名無しさん：2009/08/18(火) 22:52:46

10054 WSAECONNRESETが戻ってきました
どうも送信側のconnect()とsend()の間に間をおくと成功するようです。
send()の前にSleep()で行けました。

416 ：デフォルトの名無しさん：2009/08/18(火) 23:00:17

>>415
client側でclosesocket()していないのが原因。
send()した後、すぐにWSACleanup()しちゃうから、コネクションがリセットされてしまう。
closesocket()すれば、データが届くまで待つから大丈夫。

417 ：デフォルトの名無しさん：2009/08/18(火) 23:05:39

>>416
ありがとうございます！それだったようです。
WSAGetLastError()というのがあるってことが勉強になりました。

418 ：デフォルトの名無しさん：2009/08/18(火) 23:23:36

winsockでブロードキャスト送信するときって、ポート番号指定しなかったら
相手がとあるポートでudpもしくはtcpでrecvしていても、受信されるのでしょうか？

419 ：デフォルトの名無しさん：2009/08/18(火) 23:35:15

Winsockでは、Ethernetヘッダ部って編集できますか？IPヘッダ部まででしょうか？

420 ：デフォルトの名無しさん：2009/08/19(水) 00:12:39

raw_socket

421 ：デフォルトの名無しさん：2009/08/21(金) 05:08:05

キューっていうのは何者ですか？

422 ：デフォルトの名無しさん：2009/08/21(金) 07:01:52

ピカードに聞け

423 ：デフォルトの名無しさん：2009/08/21(金) 12:36:04

ピカード「ごまちゃんです」

424 ：デフォルトの名無しさん：2009/08/21(金) 18:30:37

winsocketでサーバー対多数クライアントを構築するのですが、どなたか手取り足取り教えてくれませんか
余った時間でかまいません。お願いします

425 ：デフォルトの名無しさん：2009/08/21(金) 18:40:15

いやです
適当な入門書でも読みながら、わからないところだけ訊きに来てください

426 ：デフォルトの名無しさん：2009/08/21(金) 18:51:21

http://www.google.co.jp/search?q=winsocket&lr=lang_ja

427 ：デフォルトの名無しさん：2009/08/21(金) 18:54:49

>>424
そんなお願いするならよぉ、
とりあえず何が必要なのか分かってるよな？

428 ：424：2009/08/21(金) 19:06:10

後ろの穴でよければお貸しします。

429 ：デフォルトの名無しさん：2009/08/21(金) 19:12:51

>>427
とりあえず今日はこれで
http://www.dotup.org/uploda/www.dotup.org55444.lzh.html

>>428？

430 ：デフォルトの名無しさん：2009/08/21(金) 20:24:03

いままでUNIXでソケットプログラミングしてたんですけど、今度Windows使う必要が出てきました。
winsockってUNIXでのノウハウは通用しますか？

431 ：デフォルトの名無しさん：2009/08/21(金) 21:04:08

PC初心者板で聞け

432 ：デフォルトの名無しさん：2009/08/21(金) 21:43:08

>>430
通用する。
関数とかライブラリの使い方なんてのはどうでもいいからな、実際。
TCP/IPのことをわかっていることが重要。

433 ：デフォルトの名無しさん：2009/08/21(金) 21:43:49

winsockってBSDソケットだから根っこの部分はまんまじゃね？

434 ：デフォルトの名無しさん：2009/08/21(金) 21:56:47

基本はほぼ同じなんだけど
*NIXで「効率的に」とかを考えると互換性が失われるのと同様かそれ以上に
細部での差はある。

435 ：430：2009/08/22(土) 00:33:18

どうもです。
基本的な部分は通用するってことですね。
ありがとうございました。

436 ：デフォルトの名無しさん：2009/08/22(土) 16:14:19

>>435
クライアント側なら、いくらか移植の手間はかかっても、
UNIXのノウハウは通用すると言えるけど、
サーバー側で、しかもマルチスレッディングが必要なレベルになってくると、
UNIXソケットの経験は、ほぼ通用しなくなるよ。
とりあえず動けばいい、なんちゃってサーバならいいけど。

437 ：デフォルトの名無しさん：2009/08/22(土) 16:34:03

キュー連続体！

438 ：デフォルトの名無しさん：2009/08/22(土) 21:59:32

「UNIXで」って一括りにしてるぐらいだから
たかが知れてるやろ

439 ：デフォルトの名無しさん：2009/08/23(日) 00:41:23

まあunixでも差違は有る。実装が違うのだから。
winsockがbsd由来とは逝ってもbsdとは違うのと同じ。
マク辺りもunix名乗ってるけど全然違うんじゃないかなあ。

440 ：デフォルトの名無しさん：2009/08/23(日) 04:00:53

>>439
WinsockとUNIX(BSD)との間の差異は大きいだろ。
少なくともCygwinやService for UNIXみたいなPOSIXエミュレータを
利用しない限り、ほぼコード無修正で移植なんて不可能だし。

それに対して、さすがにソケット仕様におけるUNIX同士の差異は
BSDがベースになっているから、ほとんど無いに等しいと言える。
(差異があってもコンパイルスイッチ等で対応可能なレベル)

Macの場合は、純粋なUNIX(Darwin)としてソケットを使用するなら、
高いBSD互換性がある。実際、Apache/Samba/Netatalk等のサーバも
最小限の変更で動いている。大きく異なるのは、NeXT由来のObjective-Cで
書かれたライブラリを使用して、(主に)GUIアプリを開発するケース。

441 ：デフォルトの名無しさん：2009/08/23(日) 04:08:45

machOS
InterfaceBuilder

442 ：デフォルトの名無しさん：2009/08/23(日) 06:12:33

>>440
データの送受信に関してはほぼコード無修正でLinuxとWinで同じコード使ってるよ。
その他のタスク(ルーティング弄ったり、NICの情報読み書きしたり)はさすがに別コード
になってるけど。

443 ：440：2009/08/23(日) 20:03:38

>>442
遅くなってしまったけど、レスありがトン。

正直な話、オイラの場合はNT4.0の時代でWinsockの情報は止まっているんだ。
今時のWinsock(2.0?)なら、ほぼ同じコードでまともな性能が実現できるのかな？
もちろんルーティングテーブルやらNIC情報の取得なんかは、UNIX間でも
互換性が乏しい部分だから、コネクション管理とデータ送受信に限定する。

そのNT4.0という大昔な話だけど、UNIX上で動くサーバ製品をNT4.0へ移植する
プロジェクトに参加してたことがあったんだ。当初は、別部署が開発した
UNIX/Win互換通信ライブラリみたいのを利用すれば、容易に移植できるみたいな
雰囲気で進んでいたんだけど、途中で性能問題にぶちあたってプロジェクト全体の
日程がひっくり返ったという苦い経験をした。

直接的な原因はマスタ・スレーブなマルチプロセス構成のUNIX実装をNTプロセスへ
直に(1対1で)割り当てたという、今から考えると大変おそまつな理由。
最終的に、マルチスレッディング構成への変更はもちろん、オーバーラップI/O使用とか、
サーバのロジック部分を除けば、通信コンポーネント部は全面的な新規開発になった。

今はそんな苦労をせずにUNIXからWindowsへ移植できるのかな？

444 ：440：2009/08/23(日) 20:07:07

>>440のカキコにお馬鹿な誤りがあったんで、自己レスで訂正

>実際、Apache/Samba/Netatalk等のサーバも

とあるけど、NetatalkはAFP(Apple File Protocol)のオプソ版実装だから、
MacOS X上で動いている事は絶対にありえない。削除するよ。

445 ：デフォルトの名無しさん：2009/08/23(日) 20:40:46

monoがどこまでいってるかは知らないが、.NETならソケット周りは共通なのでそのまま動くはず。

446 ：デフォルトの名無しさん：2009/08/24(月) 00:32:13

今のマシンスペックなら、ぶっちゃけ性能をどうこう言うほどの差は無い。

447 ：デフォルトの名無しさん：2009/08/24(月) 01:04:36

性能を期待するならOS毎にチューンが違うし
エラー対策もほぼ異なる（羽目になる）んだが
UNIXで一括りしてる時点でたいしたことないな

448 ：デフォルトの名無しさん：2009/08/24(月) 04:42:47

挙動は実装依存だしな。
たまたまNT4に移植したunixの実装依存だろ。

マクは何でもアポーのライブラリ呼ばされそうだけどな。unixとして実装しても、マクとして使う分にはいろいろ問題有るでしょ。

449 ：デフォルトの名無しさん：2009/08/24(月) 05:09:05

何も知らんのに語るな

450 ：デフォルトの名無しさん：2009/08/24(月) 09:53:36

>>449
何か知っているなら語ってくれ

451 ：デフォルトの名無しさん：2009/08/24(月) 12:48:50

>>448
知ったか乙

452 ：デフォルトの名無しさん：2009/08/24(月) 14:19:15

エンディアンが違う

453 ：デフォルトの名無しさん：2009/08/24(月) 14:36:45

ウソツカナイ

454 ：デフォルトの名無しさん：2009/08/24(月) 14:38:20

興味のない方はすみません(スルーお願いします。)
新しくコンテストを来年開きたいと思っています
プログラマー（ゲーム・ツール・）の方は
http://pc12.2ch.net/test/read.cgi/tech/1221701297/l50
のスレに来てもらえるとうれしいです。
運営も募集しています。
↓のような感じでコンテストを開始する予定です。
http://219.113.110.143/

455 ：デフォルトの名無しさん：2009/08/24(月) 19:21:23

>>454
HSPって・・・だいぶ古くないか？それに、これ、荒らし・・・・

456 ：440：2009/08/24(月) 21:51:18

みなさまレスありがトン

>>445
.NETはMicrosoft製の共通言語基盤で、momoはそのオプソ版だと理解してます。
そうであればJavaで書けばプラットフォーム非依存になる事と同じ理屈ですから、
申し訳ないけど、今のところはC言語(C++含む)でソケットプログラミングした場合における
プラットフォーム間(特にUNIX<->Windows)の移植性という主題に限定させてください。

>>446
それがですね、DeleGateというプロキシソフトがありまして、キャッシュサーバとして
利用した場合、Linuxならトラフィックが過大になっても「なんとか使える」レベルなんですが
(もちろんSquidより劣化度は悪いけど)、Windowsだと最新マシンでも「使い物にならない」ほど
性能が劣化するという事例(クレーム)を経験しています。詳しく調べていなかったのですが、
CPUやメモリの動作状況には十分な余裕はあり、どこかで引っかかっているという印象でした。
もともとDeleGateのコードは古い設計で、しかもWin移植版はオマケ程度というのが常識なので
しかたがないんですが、マシン性能だけで全ての問題が解決するわけではないこともご理解ください。

>>448
まず、UNIX間で性能チューニングに関してプログラミングで大きな差異は無いと理解しています。
また、主題からは外れますが、運用面でUNIX毎にバッファサイズやセマフォ数などの
チューニング手法、あるいはトラブルシューティング法が異なることは事実とはいえ、
どれか一つを理解していれば他のUNIXへ移っても経験は生かすことができます。
(オイラはSunOS/Solaris/HP-UX/Linuxを経験してます。)
でもそれがWindowsに移るともなれば、チューンもエラー対策も一から勉強し直しに
なるんじゃないかと思うのです。それは(運用面における)大きな差異ではないでしょうか？

(長いので続きます)

457 ：デフォルトの名無しさん：2009/08/24(月) 23:04:26

全レスうざい

458 ：440：2009/08/24(月) 23:46:48

(>>456の続き)

>>448
>たまたまNT4に移植したunixの実装依存だろ。

たしかに今時は性能が重要視されるサーバソフトの開発ではマスタ・スレーブ方式な
マルチプロセス構成はしないでしょうね。UNIXでもマルチスレッドが当たり前な時代ですから。
ただ、NT4.0時代からWindowsを離れて浦島太郎状態なので、マルチスレッド構成で最近の
Windows 200x Serverであれば本当に通信制御に関してUNIXからの移植性に問題無しなのか、
今時の設計技術動向を知っている人がいれば教えてもらいたく、質問カキコしました。
あるいは書籍やWebを紹介してもらえるだけでも(英文可)、とても嬉しいです。

>マクは何でもアポーのライブラリ呼ばされそうだけどな。unixとして実装しても、マクとして使う分にはいろいろ問題有るでしょ。

MacOSXではapache/samba/proftpd/postfix/named/cups...etcが普通に(裏で)動いていますよ。
プロセスの起動/停止はMac固有(launchd)だし、設定ファイル編集のGUIはObjective-Cライブラリで
新規開発が必要ですけど、それはネットワークプログラミングの話題からは外れますよね。
MacOSXの底辺はDawinというBSD系UNIXですし、カーネルはMach(マイクロカーネル)ですが、
そのPOSIX互換サービスは歴史が古いだけあって、互換性(移植性と性能)の問題はほぼ皆無です。
そのあたり、出来の悪いWindowsのService for UNIXとの間には絶対的な壁があります。
あるいは「いろいろ有る」という問題点を具体的に指摘してくださいませ。

459 ：デフォルトの名無しさん：2009/08/24(月) 23:59:06

何か釣りだったみたいだな。自分で調べろググレカス。

460 ：デフォルトの名無しさん：2009/08/25(火) 07:49:14

NetInfo

461 ：デフォルトの名無しさん：2009/08/25(火) 08:22:41

マカーうざい、まで読んだ

462 ：デフォルトの名無しさん：2009/08/25(火) 10:29:53

性能重視するんならIOCPとか調べてみたら

463 ：デフォルトの名無しさん：2009/08/25(火) 15:00:54

PF_INET の PF はプロトコルファミリの省略だよね。
AF_INET の AF って何の省略？アナルファック？

464 ：デフォルトの名無しさん：2009/08/25(火) 15:19:46

Auto Focus

ttp://www.google.co.jp/search?hl=ja&q=AF_INET

465 ：デフォルトの名無しさん：2009/08/25(火) 15:19:54

address family

466 ：463：2009/08/25(火) 17:47:37

>>464-465
ありがとうございました

467 ：デフォルトの名無しさん：2009/08/25(火) 23:17:14

dos攻撃をするプログラムを作りたいのですが
なかなかうまくいかないので誰かご教授お願いします。

468 ：デフォルトの名無しさん：2009/08/25(火) 23:23:34

>>467
簡単に作れると思うけど１台からじゃ効果ないな。

469 ：デフォルトの名無しさん：2009/08/25(火) 23:27:26

printf("コマンドまたはファイル名が違います\n");

470 ：デフォルトの名無しさん：2009/08/26(水) 00:01:48

とりあえずゴミパケット送ってれば、屑PGが組んだプログラムならあぼーんしそうだが。

471 ：尻行太保・戴宋：2009/08/26(水) 00:16:02

>>463
もしかして貴様、AF団十尻衆、衝撃のアナルベルトじゃねーか？

472 ：デフォルトの名無しさん：2009/08/26(水) 01:58:14

TCP?
http://tsushima.2ch.net/test/read.cgi/newsplus/1251155274/

473 ：デフォルトの名無しさん：2009/08/26(水) 19:45:28

winsocketで同時に複数のクライアントから接続要求があったとき、1つだけ接続して他は次回のループまで待たせたいのですがどうやれば良いですか？

474 ：デフォルトの名無しさん：2009/08/26(水) 21:31:03

そのままほうっておけばおｋ。レベルトリガなら次に拾える。

475 ：デフォルトの名無しさん：2009/08/26(水) 22:50:48

>>473
accept()しなけりゃ良いだけだけど何で１接続だけ受け入れたいの？
マルチスレッド嫌ならselect()使う方法とかあるけど。

476 ：デフォルトの名無しさん：2009/08/26(水) 23:19:34

以下のような場合、UDPでは動きはどうなりますか？

while{
send

recvform

受信したbufferの処理
}

この場合、recvformで受信したUDPデータをバッファにためます。
そして、バッファのデータをそのあとに処理します。
そのあとに、送信処理を行い、再びデータを受信する。
といった流れでいいのでしょうか？

たとえば、UDPのデータが二つ同時に来た場合、
先着のデータ受信中(recvform中）に、後着のデータが来た場合、
後着のデータは先着が受信中なのでrecv出来ずに破棄されるのでしょうか？
それとも上書き？されてしまうのでしょうか？
同時に来た時点で、受信サイズがたとえば同一のデータを送っていたとしても
めちゃくちゃになるのでしょうか？

477 ：デフォルトの名無しさん：2009/08/26(水) 23:36:06

OSがバッファリングする。OSのバッファが足りない場合は破棄される。

478 ：デフォルトの名無しさん：2009/08/26(水) 23:39:34

UDPって来なかったり２つ来たり前後して来たりするのに使い物になるの？

479 ：デフォルトの名無しさん：2009/08/26(水) 23:42:02

>>478
動画のようにリアルタイムで必要なデータなら古いデータが来たところで意味がない。
それに１コマがなくても前後のコマで保管したりできるから必要ない。
そういう場合にUDP。

480 ：476：2009/08/26(水) 23:58:10

破棄されるとは、後着のデータが破棄されるということでしょうか？
先着のデータは無事に受信できるとして？

というか、recvform1回でもそれぞれ別のUDPデータを2つ同時に受信できるのかー

常に受信ごとにrecvformで待ち受けしなければいけないものかとおもってた

481 ：デフォルトの名無しさん：2009/08/27(木) 00:02:19

受信しなくてもUDPの中の人がバッファリングしてくれまつ

482 ：476：2009/08/27(木) 00:25:02

バッファリングとはどういうことでしょうか？

受信しなくても受信する？？

483 ：デフォルトの名無しさん：2009/08/27(木) 00:40:52

recvformの呼び出しに関係なくいったんOS側で受信する
その後recvformの呼び出しでプログラムがOSから受け取る

484 ：デフォルトの名無しさん：2009/08/27(木) 00:50:29

>>483
つまり、先着と後着のデータ分バッファがないとだめってことですか
バッファがない場合、後着はバッファに上書きされることなく、OS側ですら受信されないということでしょうか？

でも、recvform呼ばずにOS側が受信するってそういうものなのでしょうか？
socketなんて生成しなくてもイーサネットでデータ送られるとOSが受信はするということですよね

485 ：デフォルトの名無しさん：2009/08/27(木) 00:55:49

>>484
ソケット作らなきゃUDPの中の人はバッファリングしてくれません。
イーサネットの中の人は常にデータ受信してると思うけど。

486 ：デフォルトの名無しさん：2009/08/27(木) 01:03:47

recvformで受信したデータを保存するバッファと
OSが保存するバッファは違うということですよね

OSがない場合だと、そのOSから受け取るという概念はないわけですよね
つまり同時に着た場合は、どうなるんだろう

487 ：デフォルトの名無しさん：2009/08/27(木) 01:07:42

ポート別・アプリケーション別に現在流れているトラフィックを抽出したいのですが、いい方法はありますかね？

488 ：デフォルトの名無しさん：2009/08/27(木) 01:09:15

>>486
同時に着くって言うのはないよ。
タイミングが近いってだけで、処理自体は常に1つしか行われないんだから
通信だって1つのデータを送受信中に別のデータを送受信はできない

489 ：デフォルトの名無しさん：2009/08/27(木) 01:13:22

>>488

では、

while{

recvform

受信したバッファを別のバッファにうつす

}

という処理をしておけば、受信バッファに上書きされることはありえないということでしょうか？
たとえ、近いタイミングでこようが

490 ：デフォルトの名無しさん：2009/08/27(木) 01:18:15

>>489
そうなる

491 ：デフォルトの名無しさん：2009/08/27(木) 01:28:23

>>490
別のバッファをうつしている最中に、データが来たら先ほどどなたかおっしゃってたように
OSのバッファへと一時的にいれられるわけであってますか？
それをrecvformでとりだす。

ただし、socketせいせいしている場合に限る

結局はrecvform自体、OSのバッファから取り出しているってことなのでしょうか？
オプションでタイムアウト時間指定してやるのも、このOSのバッファの中が指定した時間空なら
受信エラーをかえすってイメージでしょうか

492 ：デフォルトの名無しさん：2009/08/27(木) 01:45:02

>>491
そんな認識であっていると思うよ

Socketが必要なのは
たとえばデータが送られてきたとき、どのプログラムにそのデータを渡せばいいと思う？
Socket生成しbindさせることによって、特定ポートに送られてきたデータを特定のプログラムに渡すことができる。
もしそのポートにbindされたプログラムがなければOSはそのデータを破棄することになる。

493 ：デフォルトの名無しさん：2009/08/27(木) 02:51:12

まあM$の出来そこないOSだと破棄されるわな。
Linuxの使用を推奨する。

494 ：デフォルトの名無しさん：2009/08/27(木) 03:47:26

>>487
環境は？

495 ：デフォルトの名無しさん：2009/08/27(木) 06:27:18

winsockを使ってgethostname();とgethostbyname();で自分のIPアドレスを調べたら
http://www.ip-checker.net/
こういうサイトで調べて出てくるアドレスと違っています。これはどういうことでしょうか？

496 ：デフォルトの名無しさん：2009/08/27(木) 06:37:37

プロバイダに苦情言えば直るよ

497 ：デフォルトの名無しさん：2009/08/27(木) 07:01:54

初歩的なことかもしれませんがお願いします。

498 ：デフォルトの名無しさん：2009/08/27(木) 07:33:38

>>497
ルータがアドレス変換してるから。
NATとかでぐぐれば分かる。

499 ：デフォルトの名無しさん：2009/08/27(木) 08:22:35

>>493
linuxではbind前に遡ってデータを受信できるのか? こりゃ、吃驚だ。ｗ

500 ：デフォルトの名無しさん：2009/08/27(木) 08:45:46

>>498
ルータを介さない自分のグローバルIPを取得する関数もしくは鉄板な方法ありますか？

501 ：デフォルトの名無しさん：2009/08/27(木) 09:13:06

127.0.0.1

502 ：デフォルトの名無しさん：2009/08/27(木) 09:13:40

IPっていうな。クズ。

503 ：デフォルトの名無しさん：2009/08/27(木) 10:26:30

>>500
自分はグローバルIPアドレスをもってない可能性が高い。

504 ：デフォルトの名無しさん：2009/08/27(木) 10:28:26

>>502
なんでIPって言っちゃいけないの？

505 ：デフォルトの名無しさん：2009/08/27(木) 10:49:26

「IPアドレス」のことを、単に「IP」と言うな、と。

506 ：デフォルトの名無しさん：2009/08/27(木) 10:57:27

ネットワークプログラミングのスレだし、正確な用語を使わないとまぎらわしい。

507 ：デフォルトの名無しさん：2009/08/27(木) 11:10:14

はあ？
だから何でIPと言っちゃいけないの？

508 ：デフォルトの名無しさん：2009/08/27(木) 11:15:59

「グローバルIP」などというのは無いからだ。無いものを取得する事は出来ない。
分ったら消えろ。

509 ：デフォルトの名無しさん：2009/08/27(木) 11:23:21

説明できないの？
アホですか？

510 ：デフォルトの名無しさん：2009/08/27(木) 11:40:14

電話番号聞くときに「お前の電話教えてよ」と聞くのと同じだな
意味はわからなくないが、厳密に言えば間違い

511 ：デフォルトの名無しさん：2009/08/27(木) 11:57:36

コミュニケーション能力の無い奴を構ってやるなよ…

512 ：デフォルトの名無しさん：2009/08/27(木) 12:02:39

>>509
理解できないの?
アホ確定ですね。

513 ：デフォルトの名無しさん：2009/08/27(木) 13:12:08

むかしっから釣り的な意味であるんだよ>>IP
スルーしる

514 ：デフォルトの名無しさん：2009/08/27(木) 13:17:17

>>502
お前も二度と「レス」とか「携帯」とか使うなよ

515 ：デフォルトの名無しさん：2009/08/27(木) 13:24:18

アドレスって呼べば良いのに。

516 ：デフォルトの名無しさん：2009/08/27(木) 13:25:15

>>514
あぁ、見かけたら「使うな。クズ」と言っていいぞ。ｗｗ

517 ：デフォルトの名無しさん：2009/08/27(木) 13:52:06

netstatコマンドで接続元のIPと接続先のIPが表示できるけど
ipv6とかで、IPが長いと省略されてしまうんだけど
IPを省略しないで表示させるにはどうしたらいいのかな。

518 ：デフォルトの名無しさん：2009/08/27(木) 14:27:15

わざとやってんのか、いいかげんにしろ

519 ：デフォルトの名無しさん：2009/08/27(木) 14:37:52

普通IPっていったらIPアドレスだろ
いちいち反応するやつの方がうぜえ
日本語の省略文化が判ってない馬鹿

520 ：デフォルトの名無しさん：2009/08/27(木) 15:15:29

WikipediaをWikiと省略するほうが馬鹿だろ。

521 ：デフォルトの名無しさん：2009/08/27(木) 15:32:02

Wiki - pedia たが？

522 ：デフォルトの名無しさん：2009/08/27(木) 15:39:22

>>518
わざととしか思えないからスルー白

523 ：デフォルトの名無しさん：2009/08/27(木) 17:00:12

>>520
どっちも同じ。

524 ：デフォルトの名無しさん：2009/08/27(木) 17:19:32

ああ、バカの程度が同じ、ってことか。びっくりした。

525 ：500：2009/08/27(木) 18:25:53

もうやめてくれ俺はただ>>495のサイトで出てくるようなアドレスを自分のPC内で取得したいだけなんだ

526 ：デフォルトの名無しさん：2009/08/27(木) 18:31:28

>>525
自分のアドレスがプライベートだったら内部だけで解決するのは無理だな
ダイナミックdnsの自動更新の仕組みとか調べたら参考になるかも

527 ：デフォルトの名無しさん：2009/08/27(木) 18:35:47

シェルスクリプトをシェルってゆーな。

528 ：デフォルトの名無しさん：2009/08/27(木) 18:39:28

ルーターがWAN側アドレスを教えてくれるやつもあるよね
SOAPとかで取得するやつ

529 ：デフォルトの名無しさん：2009/08/27(木) 18:44:12

>>528
それでもPC内だけでって要望には応えられないんだよな

530 ：デフォルトの名無しさん：2009/08/27(木) 18:48:07

NAT越しでネットにつないでいるのであれば完全に絶望だな

531 ：デフォルトの名無しさん：2009/08/27(木) 19:04:50

>>500
一般的な方法は存在しない。
一般的でない方法ならたくさんあるのでそれを何通りも使って保険かける。

532 ：デフォルトの名無しさん：2009/08/27(木) 20:31:28

おまえの電話教えてよ
↓
おまえの番号教えてよ
↓
おまえ何番だっけ

533 ：517：2009/08/27(木) 22:14:11

どなたかお願いします

534 ：デフォルトの名無しさん：2009/08/27(木) 22:15:31

>>500
ttp://www.ip-checker.net/ のようなサイトをHTTPで叩いて
出てきたHTMLをパースすればOK

535 ：デフォルトの名無しさん：2009/08/28(金) 00:19:54

bind処理で、ポートだけ指定してbindするのと
ポートとIPの両方を指定してbindするのでは、

負荷って変わりますか？
bindしないIPとbindしないポート宛のデータが、bindするデータと混ざって送られてくるとして

とあるIP以外からは、とあるポートに送られてこないデータ送信があるとします。
そんな中で、IPとポートの二つをbindする必要があるかってことです。
ポートだけでも受信しないんだから、IPのbindしなくてもいいのでは？
負荷が変わらないもしくは、負荷が下がるならそっちのがいいような

536 ：デフォルトの名無しさん：2009/08/28(金) 00:22:09

すみません、ついでにもう一つ
ブロードキャストで送信した場合って、ポートをbindしていたら受信できませんよね？
ブロードキャストはポート指定して送信できますか？

537 ：デフォルトの名無しさん：2009/08/28(金) 00:47:09

535は放置で

538 ：デフォルトの名無しさん：2009/08/28(金) 00:49:07

ルータを通して出てくるアドレスって普通のIPアドレスみたいにダブったりしないんですか？

539 ：デフォルトの名無しさん：2009/08/28(金) 01:00:49

アイちゃん壊れちゃったね、引退しよっか

http://chimp-sanctuary.org/oursanctuary/hitori.htm
引退（ヒトが勝手に引退と決めるだけなのですが）となったチンパンジーは、
人目につかない非公開の場所で単独飼育されるのが一般的です。それは、
40～50年と言われるチンパンジーの寿命を考えると、ほとんどの人生をその
狭い檻の中で送ることになります。

540 ：デフォルトの名無しさん：2009/08/28(金) 01:04:46

>>538
何が聞きたいのかさっぱりわからん

541 ：デフォルトの名無しさん：2009/08/28(金) 01:08:55

>>540
たとえば111.111.111.111がルーターを介したアドレスだとしたら、111.111.111.111に何か送ればその人に確実に届いて他のPCに行くことは無いのかということです。

542 ：デフォルトの名無しさん：2009/08/28(金) 01:13:03

すみません、>>535お願い致します。

bindでポートとIP両方指定した場合と、ポートだけ指定した場合では
負荷は違うのでしょうか？弾く層が違う？

ちなみにそのポート宛に届くのは、bindするIPアドレスだけからだとして

543 ：デフォルトの名無しさん：2009/08/28(金) 01:44:22

>>533
linuxなら /proc/net/tcpとか、/proc/net/udpとかに生データが書いてあるんで、
それ解析すればいい。フォーマットは見たら大体分かる。
その他のOSなら知らね。

544 ：デフォルトの名無しさん：2009/08/28(金) 01:49:07

なんだかプログラミング以前の質問が多いけど、そういうのは別のところでやった方がいいとおもうよ。

545 ：デフォルトの名無しさん：2009/08/28(金) 02:01:26

>>541
ルータの設定による。

546 ：デフォルトの名無しさん：2009/08/28(金) 02:04:59

>>545
たとえばどんな影響が出ますか？

547 ：デフォルトの名無しさん：2009/08/28(金) 02:08:04

目的のPCに届くかもしれないし、パケット捨てられるかもしれないし、別のPCに届くかもしれないし、エラーが帰ってくるかもしれない。

548 ：デフォルトの名無しさん：2009/08/28(金) 03:02:57

>>535,542
一般的にbindでIPアドレス指定が必要になるのは、
ネットワークインターフェイスが複数(2コ以上)ある場合で、
受け付けるインターフェイスを限定したい場合だけ。
ルータみたいに。普通のアプリでは指定する必要なし。

549 ：デフォルトの名無しさん：2009/08/28(金) 05:30:57

>>547
普通のアドレスと同じように使えるということですか？

550 ：デフォルトの名無しさん：2009/08/28(金) 07:21:02

551 ：デフォルトの名無しさん：2009/08/28(金) 07:53:02

>>549
普通のアドレスってなんだよ
異常なアドレスってのもあるのか？

552 ：デフォルトの名無しさん：2009/08/28(金) 07:58:24

>>548
２個以上有る場合は絶対していしないといけないってことでしょうか？

553 ：デフォルトの名無しさん：2009/08/28(金) 08:03:59

>>535,542
IPってゆうな。クズ。

554 ：デフォルトの名無しさん：2009/08/28(金) 08:30:10

>>552
受信したいインタフェースを限定したいなら。

555 ：517：2009/08/28(金) 11:12:19

>>543
ありがとうございます。調べてみます。

556 ：デフォルトの名無しさん：2009/08/28(金) 11:14:08

>>552
IPをふたつ持ってても、どっちからも受信したいなら指定する必要はない
（というかどっちのIPでも着信するようにデフォルトで設定している）
どれかひとつのIPでだけ受信したいなら設定する必要がある。

557 ：デフォルトの名無しさん：2009/08/28(金) 11:20:25

IPってゆうな。クズ。

558 ：デフォルトの名無しさん：2009/08/28(金) 11:23:08

　IP
　　- |　　　 ←不機嫌な顔
　IP

559 ：デフォルトの名無しさん：2009/08/28(金) 20:15:03

IP抜くぞｺﾞﾙｱ

560 ：デフォルトの名無しさん：2009/08/29(土) 00:27:58

　IP
　　- ）　　　 ←愉快な顔
　IP

561 ：デフォルトの名無しさん：2009/08/29(土) 00:41:20

プログラム以前のインターネットプロトコル話は通信板でもどうぞ。

562 ：デフォルトの名無しさん：2009/08/29(土) 07:04:41

米人は口で感情を読み取り、日本人は目で読み取る、ってどっかに書いてあった。(^^;

563 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 14:11:34

IPは、IPアドレスの略だろJK
そういえば、HPをいちいちwebページと訂正する要領の悪いしったかいたなｗ
（初心者相手にそこまで説明する必要ないんだよｗ）

564 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 14:26:04

HewlettePackard

565 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 14:34:55

>>563
省略するなよ Internet Protocol Address だ。

566 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 15:14:29

それじゃあソースなのかデストなのか判らんじゃないか
省略するなお

567 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 15:17:29

v4かv6かも必要だお

568 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 16:39:23

Internet Protocol Address のことを、シロウトはアイピー、プロはアドレスって略すんだよ。

569 ：デフォルトの名無しさん：2009/08/30(日) 21:00:36

>>568
するどいｗ

570 ：デフォルトの名無しさん：2009/08/30(日) 22:00:24

じゃあああアドってことにしようぜ

571 ：デフォルトの名無しさん：2009/08/30(日) 22:45:54

まあプロトコル無視したプロなんだろうな

572 ：デフォルトの名無しさん：2009/08/30(日) 23:18:41

IPと略されると、それがIPアドレスかプロトコルかどっちだってことだけど、
アドレスって略されると、IPアドレスなのかMACアドレスなのか、メモリアドレスなのかとかいろいろ可能性があって逆に迷惑だぞ

IPと略されたほうがまだいい

573 ：デフォルトの名無しさん：2009/08/30(日) 23:25:34

>>572
IPと言った場合、プロトコルのことだぞ。

574 ：デフォルトの名無しさん：2009/08/30(日) 23:40:21

>>572 素人は黙ってろ

575 ：デフォルトの名無しさん：2009/08/31(月) 00:03:41

>>573
携帯電話のことを携帯っていわないの？

576 ：デフォルトの名無しさん：2009/08/31(月) 00:09:06

>>575
携帯電話のことを話って言うのか？

577 ：デフォルトの名無しさん：2009/08/31(月) 00:12:07

IPといったらアドレスで同意だろ
IPは、UDPとか答えてたら頭おかしい

578 ：デフォルトの名無しさん：2009/08/31(月) 00:14:58

IPといったらInternet Protocolで同意だろ
IPは、アドレスとか答えてたら頭おかしい

579 ：デフォルトの名無しさん：2009/08/31(月) 01:01:18

携帯電話の省略形は「ケータイ」

580 ：デフォルトの名無しさん：2009/08/31(月) 01:02:59

> IPは、UDPとか答えてたら頭おかしい
意味不明。素人は黙ってなさい。

581 ：デフォルトの名無しさん：2009/08/31(月) 01:04:05

正式名称はNPだが今はRPとかSPとか言われとるねw

582 ：デフォルトの名無しさん：2009/08/31(月) 09:20:19

>>579
言ってろ低脳

583 ：デフォルトの名無しさん：2009/08/31(月) 09:27:03

「ケータイ」はPHSとかの似非携帯の通称だよ

584 ：デフォルトの名無しさん：2009/08/31(月) 09:33:23

>>582-583
残念ながら、キミタチが無知なだけ。

585 ：デフォルトの名無しさん：2009/08/31(月) 10:04:46

携帯自体はそれだけで意味をなさないから
携帯電話をケータイと略しても意味が通じるが
IPはそれだけで意味を持つからダメ

586 ：デフォルトの名無しさん：2009/08/31(月) 12:17:27

おまえら他所でやれ

587 ：デフォルトの名無しさん：2009/08/31(月) 14:45:32

いいよ
自称プロなんて見てればすぐばれるんだからw

588 ：デフォルトの名無しさん：2009/08/31(月) 15:18:11

589 ：デフォルトの名無しさん：2009/08/31(月) 17:39:28

かつては勉強になるレスもあったけど最近はくだらない話ばかりに見える
きっと漏れが成長したんだろう

590 ：デフォルトの名無しさん：2009/09/01(火) 06:06:18

電話機能のない携帯端末もあるけどなあ。機能で呼ぶべきだから電話と略すべき。
携帯傘のことを携帯とは呼ばずに傘と呼ぶのと同様。

591 ：デフォルトの名無しさん：2009/09/01(火) 07:00:11

正式名称は移動電話

592 ：デフォルトの名無しさん：2009/09/01(火) 07:26:11

いつまでスレチガイな話を引っ張るの？俺も便乗しちゃうよ？

＞携帯【けいたい】
＞
＞(１)身につけたり，手に持ったりして持ち運ぶこと。「―品」「雨具を―する」
＞(２)「携帯電話」の略。 →携帯電話
＞提供元：「大辞林第二版」

というわけで、携帯は既に携帯電話の略称として定着しているとみてよいでしょうが

593 ：デフォルトの名無しさん：2009/09/01(火) 08:08:06

正式名称は自動車電話

594 ：デフォルトの名無しさん：2009/09/01(火) 16:24:34

一般用語に規格など存在しない、その時その時の使われ方によって変化する。
最新版の>>592のようなものが妥当だろう

595 ：デフォルトの名無しさん：2009/09/01(火) 19:09:21

IP電話もあるよ

596 ：デフォルトの名無しさん：2009/09/01(火) 21:10:03

VoIP

597 ：デフォルトの名無しさん：2009/09/02(水) 21:11:38

>>591-593
「電話」はシステムの名前だから「携帯電話機」「携帯電話端末」だな。
電話機を電話と略すのは、IPアドレスをIPと略すのに等しい。

598 ：デフォルトの名無しさん：2009/09/02(水) 21:19:08

施設設置負担金を電話加入権と略すのに等しい

599 ：デフォルトの名無しさん：2009/09/02(水) 21:42:56

>>598
それって略じゃなくて別名とか俗称・別称という感じだが

600 ：デフォルトの名無しさん：2009/09/03(木) 00:31:25

広く定着すればそれが正式名称
もしそれが絶対ダメだというのなら
日本語は今頃酷く話し辛いものになっていたと思うよ

601 ：デフォルトの名無しさん：2009/09/03(木) 00:47:22

いくら広まっても略語や俗称は正式名称ではない。

602 ：デフォルトの名無しさん：2009/09/03(木) 01:05:42

略称でいいよ。

603 ：デフォルトの名無しさん：2009/09/03(木) 10:02:16

「ホームページ」とかな。
誤用はあくまでも誤用。

604 ：デフォルトの名無しさん：2009/09/03(木) 10:09:42

HP は Hewlett Packard

605 ：デフォルトの名無しさん：2009/09/03(木) 20:25:25

いいえ、ヒットポイントです

606 ：デフォルトの名無しさん：2009/09/03(木) 22:41:01

だから馬力だって言ってんだろ。

607 ：デフォルトの名無しさん：2009/09/03(木) 23:49:44

すみません、100Mbpsとか56kbpsとかどういうことでしょうか？

データを送信し終わった段階から、相手が受信し始める　段階までの速度でしょうか？
それとも、データを送信して、相手が受信し、相手がそれに対しデータを送信し、最初に送った相手が受信しはじめる時間でしょうか？

厳密には、プログラムでいうと、sendが終わった段階から、相手がrecvで受信しはじめるまでの時間でしょうか？

608 ：デフォルトの名無しさん：2009/09/04(金) 00:07:32

あなたが欲しいその値はレイテンシと言う

100Mbpsとか56kbpsとかはスループットと言って、
データを途切れなく連続で送り続けたときに毎秒どれだけ送れるかというもの
100Mbpsなら1秒あたり100メガビット≒12メガバイト
例えば10ギガバイトのデータを送信あるいはダウンロードするには13分ちょいかかる計算になる

609 ：デフォルトの名無しさん：2009/09/04(金) 00:10:34

>>608
100Mbpsなら、地球の裏側だろうが、東京から大阪だろうがダウンロードにかかる
時間にはかわりないのでしょうか？

あと、100Mのデータを途切れなくおくるとありますが、
途切れなく送るプログラムってどんな感じなのでしょうか？
ＣＰＵにも依存するのでしょうか100Mbpsは

610 ：デフォルトの名無しさん：2009/09/04(金) 00:23:50

ここで説明しても理解できやしないんだから、まず本を読め
答えを聞いても別の疑問が沸いてくるだけだろう
時間の無駄だ

611 ：デフォルトの名無しさん：2009/09/04(金) 00:31:04

>>607
プログラミングと関係ない気がするが

単位時間当たりの伝送ビットだよ。

＞データを送信し終わった段階から、相手が受信し始める
とか
＞データを送信して、相手が受信し、相手がそれに対しデータを送信し、最初に送った相手が受信しはじめる時間
とかは関係ない

プログラムのことは関係なく、回線のあるポイントを監視して、1秒間に何ビット通過したかってだけのこと。

たとえば、交通量調査員が、ある道で交通量を計測している。
その交通量調査員は自分の前を通った車の数だけチェックしているわけだ。
その道路の信号機の位置や交差点の有無は考慮しない。
ある時間から、ある時間までをただ数えているだけ。

612 ：デフォルトの名無しさん：2009/09/04(金) 00:32:58

もちろんレイテンシも関係がある
電気信号や光の速度も無限ではないし、途中でルータ等の機器を経由するごとにちょっとずつ時間を食うが・・

そうだな・・・たとえば川を想像してみろ
流れる水がデータだと思え
最初、川にまったく水が無い場合、上流から放水を始めると、それが下流に届くまでいくらか時間がかかる
この時間がレイテンシ、これは川の距離による
しかしいったん最初の水が来れば、あとは川の容量が許す限り次々に水が来る
この流量がスループット、これは川の広さによる

ほんのちょびっとだけ水が欲しい、というときは川がいくら広くてもあんまり意味がなく、川の距離の影響が大きい
ものすごい大量の水が必要だ、というときは、最初の水が来るまでの時間なんかささいなことで、
最終的にどれだけ大量の水を送れるか、つまり川の広さが重要になる

100Mbpsとか56kbpsとかは、川の広さの方を表す値だ

613 ：デフォルトの名無しさん：2009/09/04(金) 00:43:58

>>607
>100Mbpsとか56Kbps
回線の速度のことかな
どこからどこまではググってね…

>データを送信し終わった段階から、
>相手が受信し始める段階までの速度
自分から相手つまり上りの回線速度
(相手からは下りになるのかな？)

>それとも、データを送信して、相手が
>受信し、相手がそれに対しデータを送信し、
>最初に送った相手が受信し始める時間でしょうか？
相手から最初に送った相手(自分？)
つまり下りの回線速度

おっと…いつの間にか進んでる
何を書きたいんだ自分はorz

>>609
>100Mbpsなら、地球の裏側だろうが、
>東京から大阪だろうがダウンロードに
>かかる時間に変わりないのでしょうか？
回線のトラフィックや他の回線速度によって
わずかに違うかもしれない

極端な例だが、自分のノートは無線LANルーター(54Mbps)で
ネットに接続しているが
PCから無線LANルーター間は高速でも
ルーター以降がPHS(64Kbps)なので
とてつもなく遅いorz

614 ：デフォルトの名無しさん：2009/09/04(金) 00:51:39

やはりというか
初心者のただの自問自答か

615 ：デフォルトの名無しさん：2009/09/04(金) 01:07:08

何か最低限の知識も無いのにネットワーク騙ってるのこのスレ

616 ：デフォルトの名無しさん：2009/09/04(金) 01:21:01

そうだよな･･･ bpsとかプログラミングの話じゃないよな･･･
今後その手の質問が来たらどこかに誘導するか･･･

617 ：デフォルトの名無しさん：2009/09/04(金) 11:12:51

BPSといえばブラックオニキス

618 ：デフォルトの名無しさん：2009/09/04(金) 15:22:12

TCPはUDPと違って、複数回送信した後に受信した場合、一括で取得するみたいだけど
送信した単位で取得するにはどうすればいいの？
自前でデータサイズヘッダーを付加して送信するとかしないとダメですか

619 ：デフォルトの名無しさん：2009/09/04(金) 15:26:35

>>618
そういうこと。 >>114 参照ね。

分断や結合の考慮が必要なので
ユニークな終端記号やヘッダにｻｲｽﾞを乗せて大きさでまとまる　といった作業が必須になる

620 ：デフォルトの名無しさん：2009/09/04(金) 15:36:50

ありが㌧

621 ：デフォルトの名無しさん：2009/09/04(金) 22:43:29

ユーモアな終端記号の例: 終わりだぴょんほげーうほっいいデータなど

622 ：デフォルトの名無しさん：2009/09/04(金) 23:26:16

BPS
http://say-move.org/comeplay.php?comeid=22411

623 ：デフォルトの名無しさん：2009/09/05(土) 00:46:28

winsockで
相手がソケットを破棄したかどうか調べる方法教えて
調べてもHTTPのサンプルばっか

624 ：デフォルトの名無しさん：2009/09/05(土) 00:55:41

feof(s)

625 ：デフォルトの名無しさん：2009/09/05(土) 09:39:07

>>623
HTTPはTCP/IPなので問題なかろう

626 ：デフォルトの名無しさん：2009/09/05(土) 10:26:41

破棄の定義によっては難しいぞ。破棄 == closeなら掲示板で聞くより簡単だが。

627 ：デフォルトの名無しさん：2009/09/05(土) 12:51:52

NULLパケットを定期的に送ってタイムアウトしたら閉じる
おれはそうしてる

628 ：デフォルトの名無しさん：2009/09/05(土) 13:13:39

KEEPALIVE

629 ：デフォルトの名無しさん：2009/09/05(土) 18:52:59

UDPで100KBのデータとか送れるんですか？

1回recvfromしたとき、バッファには100kbはいるんでしょうか？

630 ：デフォルトの名無しさん：2009/09/05(土) 18:58:23

そうだな
試してみればわかることだ

631 ：デフォルトの名無しさん：2009/09/06(日) 00:33:40

ＵＮＩＸネットワークプログラミングの第３版の邦訳ってまだでていないですよね？
Amazonでググってもでてこないし。

これはなんだろう？「購入できません」だし。
http://www.bk1.jp/review/386665

632 ：６２９：2009/09/06(日) 08:41:23

すみません、お願いします。

633 ：デフォルトの名無しさん：2009/09/06(日) 10:38:22

そんなお願いするならよぉ、
とりあえず何が必要なのか分かってるよな？

634 ：デフォルトの名無しさん：2009/09/06(日) 10:54:20

>>632
100KBくらい送れなきゃストリーミングなんて出来ないわけだが。
もしかしたら一回で100KB送りたいわけ？何のために？

635 ：デフォルトの名無しさん：2009/09/06(日) 11:00:17

送れる場合もある、送れない場合もある。
送れてかつ受信できたらな100kb入る。

636 ：６２９：2009/09/06(日) 22:21:17

1回でUDPを100kb受信するには

recvfrom　のオプションで100kbにすればいいのでしょうか？
recvfrom自体はきっと何回もするんですよね

637 ：デフォルトの名無しさん：2009/09/06(日) 23:30:21

>>636
100Kまで取れるかどうか知らないけど、
アプリケーションで処理したほうが良いと思うよ
約1.5Kのパケット一つでもロスしたら100K全部ダメになっちゃうからね

638 ：デフォルトの名無しさん：2009/09/06(日) 23:33:18

>629
IPとUDPのRFC読め

639 ：637：2009/09/06(日) 23:33:53

追記
recvfromは一回だけ
setsockoptionでバッファサイズを100kB以上にしないと
ってゆいか、出来るかどうかわからないし止めた方がいい

640 ：デフォルトの名無しさん：2009/09/06(日) 23:50:17

>>636
何で一回で100KBを受信したいんだ？
しかもUDPで。

641 ：デフォルトの名無しさん：2009/09/06(日) 23:56:51

>>636

>>3にある「UNIXネットワークプログラミング」を読みな。
TFTPの実装がソース付きで詳しく解説されてる。
TFTPというのは、UDPを使ったファイル転送プロトコル。
だから、原理的には100Kbyteでも100MByteでもUDPで転送できる。

642 ：デフォルトの名無しさん：2009/09/07(月) 00:11:10

100kを1回のsendtoで送るためには、経路中にフラグメントされたIPパケットを
拒否するルータがいない事、UDPを送る前にARPエントリが存在する事が確認さ
れている事。などの条件を満たさなければならない。
これらの条件がそろった時に100kのデータを一回で送る事が出来る。

さらに、出来ない場合を検出するために、必要な(フラグメントを許さないルー
ターからの)ICMPを破棄しない事(素人が設定したファイアウォールは破棄する)も必要。

643 ：デフォルトの名無しさん：2009/09/07(月) 21:34:06

クライアントプログラムの実行パスって取得する方法ありますか？

644 ：デフォルトの名無しさん：2009/09/07(月) 21:36:24

「実行パス」ってなんだ?

645 ：デフォルトの名無しさん：2009/09/07(月) 21:42:49

そのクライアントとやらが組み込み機器上で動いてたら
パスというかファイルシステムがそもそも存在しないかもしれんぞ
組み込みっても携帯くらいリッチだと余裕であるけどさ・・

646 ：デフォルトの名無しさん：2009/09/07(月) 21:50:35

>643
クライアントプログラムに問い合わせればいいんじゃね？

647 ：デフォルトの名無しさん：2009/09/07(月) 21:57:42

サーバーが取得して何をしたいのが疑問だ。
理由も無く取得すると、スパイプログラムと言われるぞ。

648 ：デフォルトの名無しさん：2009/09/07(月) 22:03:33

いや、MicrosoftUpdateが前に64bitのIEでアクセスしたときに32bitのIEで自動起動しなおしたから
なんかクライアントブラウザのパスでも取得してるのかと思って。

649 ：デフォルトの名無しさん：2009/09/07(月) 22:06:40

ActiveXコントロールならローカルの資源にアクセスし放題だよ

650 ：デフォルトの名無しさん：2009/09/07(月) 22:14:32

>>648
アドオンインストールでもしたんじゃないの？

651 ：デフォルトの名無しさん：2009/09/07(月) 22:16:00

>>648
そりゃブラウザが自分の判断で（何かの必要を感じて）再起動してるだけだ

652 ：デフォルトの名無しさん：2009/09/07(月) 23:41:48

>>648
クライアントのプログラムが、自身の責任でアクセス可能なものを使う
のはなんら問題ない。問題はサーバーに送って何をするかだ。
不特定のクッキー情報を送るだけでもスパイプログラム認定されてるぞ。

653 ：デフォルトの名無しさん：2009/09/07(月) 23:52:04

100kbのデータをUDPやTCPで1回で送るのと
1kb×100回で送るとなると、まったく別のデータ扱いになるのでしょうか？
そういうのってアプリでどう処理すればよいのでしょうか？

また、TCPだと毎回、それでコネクション張るわけですか

654 ：デフォルトの名無しさん：2009/09/08(火) 00:04:32

お前、調べる気全然ないのか? まさか全部ここで聞いて作るつもりか?

655 ：デフォルトの名無しさん：2009/09/08(火) 00:13:01

>>653
UDPなら分割してファイルに書き込んだり、ファイルから分割して読み込んだり
ってのとおなじ。
たまに壊れてるけど。

656 ：デフォルトの名無しさん：2009/09/08(火) 00:15:30

>>655
ありがとうございます。
分割サイズってどれくらいがいいのでしょうか？
TCPとUDPじゃ分割サイズ違う方がいいのでしょうか？

657 ：デフォルトの名無しさん：2009/09/08(火) 00:23:04

TCPはどのように送ってもすべて良きに計らってくれるから気にしないでおｋ
UDPは・・・500バイトくらい？もしくは1500バイトくらい

658 ：デフォルトの名無しさん：2009/09/08(火) 00:45:05

>>657
よきに計らってくれる　笑

その500や1500の根拠ってあるのでしょうか？
普通に考えたら大きいほうが早く処理がすむようなきがするのですが、
TCPについてもそんなイメージが

659 ：デフォルトの名無しさん：2009/09/08(火) 00:52:43

UDPよりもっと下の層が、そんなに大きなパケットを扱えないから
MTUでぐぐってみるよろし

660 ：デフォルトの名無しさん：2009/09/08(火) 00:53:56

>>658
大きいとロスする可能性があがるでしょ。
あと、相手がその大きさを受け入れられるとは限らない。

661 ：デフォルトの名無しさん：2009/09/08(火) 00:55:02

お、なんだ、大人の時間がはじまったか

662 ：デフォルトの名無しさん：2009/09/08(火) 01:01:14

俺と同じ想像をしたようだな同士よ。

663 ：デフォルトの名無しさん：2009/09/08(火) 01:04:35

>>659
TCPの場合はいいのでしょうか？

というか、10Kのデータとかを1K分割で送ってもTCPと違って続きのデータとしは
みてれくないのですよね

664 ：デフォルトの名無しさん：2009/09/08(火) 01:08:49

>>663
ソケットは届いたデータをアプリケーションに渡すだけ。
どうか意釈するかは、アプリケーション次第。

665 ：デフォルトの名無しさん：2009/09/08(火) 01:14:26

>>664
たとえば、recvで毎回決まったデータをアプリケーションに渡そうとしても
毎回同じデータレングスが渡せるとは限りませんよね
1回目が1000で2回目が500で3回目が1500とか
そういうのって、相手がまだデータを途中までしかおくってきてないとか関係あるのでしょうか？

recvする際に、1パケットのサイズを指定してやれば
recvの受信サイズがまばらになることはないのでしょうか
3000とかをオプションで指定してやっても3000受信できることもあれば、1000しか
受信できないこともあったりと、あるとは思うのですが

666 ：デフォルトの名無しさん：2009/09/08(火) 01:22:01

受信サイズが毎回違っても問題ないようなプログラムを書けばいい。

667 ：デフォルトの名無しさん：2009/09/08(火) 01:28:56

>>663
そのあたりの面倒を全部引き受けてくれるのがTCP
パケットの順序がバラバラになっても一部が失われても再送したりして復元してくれるし
相手が忙しそうなら送信スピードを自動的に調節したりもする
UDPはパケットが失われたり順序が入れ替わったり同じパケットが2度届いたり
等の現象にすべて自分で対処しなければならない

>>665
TCPは複数のsendを1つのパケットにまとめて転送効率を上げたり
送信スピードを調節してゆっくり送ったりする機能があるので
sendした分が実際に送られるパケットサイズと一致するとはまったく限らないし
sendしたバイト数とrecvできるバイト数が一致するなどとはまったく期待できない
recvは1バイトでも今すぐ返せるデータがあればさっさと返すような仕様になってるから、そういう動作をする
例えばGIFのインタレース表示をしたいブラウザなんかは、一部でもデータが到着したら
その部分はもう描画し始めたいわけだから、そういう仕様でないと困る
固定サイズずつ処理したいアプリケーションは、そのサイズが来るまで繰り返しrecvを呼べばよい

668 ：デフォルトの名無しさん：2009/09/08(火) 01:50:54

>>663
たとえばだな、イーサネットのフレームサイズは 1500 バイト程度だ
IPが連続したデータとして、ある程度はめんどう見てくれるけど
UDP には到達保証を行う機能がないので 10k 送った中で 1 フレーム
でもエラーを起こすと 10K 全部が全滅

669 ：デフォルトの名無しさん：2009/09/08(火) 07:14:16

またこの話題か・・・
ネットワークプログラミングってこの話題しかないし
この話題には回答者がいっぱい出てくるねｗ

670 ：デフォルトの名無しさん：2009/09/08(火) 08:04:58

毎回、受信するサイズが違うのにそれらを一つのデータとするようなプログラムって
どんな感じになるのでしょうか？

TCPならコネクション切断されるまでが一つのデータ？
UDPならその境目がないような

671 ：デフォルトの名無しさん：2009/09/08(火) 08:12:45

毎回受信するサイズが同じだったら一つのデータにできるのか？
だったら簡単だろ。

672 ：デフォルトの名無しさん：2009/09/08(火) 08:13:16

なんか適当にぐぐってサンプルコード探して読んでみろ

673 ：デフォルトの名無しさん：2009/09/08(火) 08:33:50

データの頭に長さをデータとして持つとか
このデータが来たら一つのデータ終わりとか

674 ：デフォルトの名無しさん：2009/09/08(火) 08:50:45

UDPにおいて、単一ソケットで複数個所と通信するのと、
通信先分ソケットを作るのではどっちが効率いいんだろう
必要分のバッファをソケットに確保しておけば変わらない？

675 ：デフォルトの名無しさん：2009/09/08(火) 12:27:18

>>674
一つのスレッドが一つのソケットで通信するようにして、
ソフトウェアスレッドをハードウェアスレッド数作成するのが一番いい。

676 ：デフォルトの名無しさん：2009/09/08(火) 13:02:49

ソケットが一つなのに複数スレッドで何やるん？

677 ：デフォルトの名無しさん：2009/09/08(火) 13:03:38

ああ分かったごめん何でもない＾＾；

678 ：デフォルトの名無しさん：2009/09/08(火) 19:30:32

複数の相手と通信する場合、
・ひとつのソケット
・通信先の数のソケット
どっちがいい？ってことだから間違ってはないんじゃないの？>>675-676

679 ：デフォルトの名無しさん：2009/09/08(火) 19:33:47

675=677 じゃなくて 676=677 なのか

680 ：デフォルトの名無しさん：2009/09/08(火) 19:54:57

そういう事を疑問に思うレベルの奴がUDP使うと絶対に嵌る。

681 ：デフォルトの名無しさん：2009/09/08(火) 20:45:25

ネットワークプログラミングでネットワークがつながらない時にもなんとか処理してくれと言われたんだけど
こいつは頭がいかれているのか、それとも何か方法があるのか

682 ：デフォルトの名無しさん：2009/09/08(火) 20:50:26

ワラタｗ

683 ：デフォルトの名無しさん：2009/09/08(火) 20:50:47

そのなんとかを考えるのがお前の仕事じゃないのか? 思いつかない降参しろ。

684 ：デフォルトの名無しさん：2009/09/08(火) 20:55:44

>>681
上司か？ｗ
さらに上に相談して解雇してもらえｗ

685 ：デフォルトの名無しさん：2009/09/08(火) 20:57:03

迂回回線を引くしかないな

686 ：デフォルトの名無しさん：2009/09/08(火) 21:00:07

>>681
ローカルにキャッシュ置いといたりするのはよくやるけど。
あと、接続に失敗したらsleepして、ネットワークが回復したら再トライとか。

687 ：デフォルトの名無しさん：2009/09/08(火) 21:00:37

cacheだろ常考

688 ：デフォルトの名無しさん：2009/09/08(火) 21:01:31

たぶんそういうことじゃないんだろうな。

689 ：デフォルトの名無しさん：2009/09/08(火) 21:05:51

>>681
あらかじめクライアント側に自動的にあらゆるデータを改ざんするプログラムを仕込んでおけばおｋ

690 ：デフォルトの名無しさん：2009/09/08(火) 23:00:56

通信出来ませんって表示すればOK
プログラムが固まってしまうとかはNG

691 ：デフォルトの名無しさん：2009/09/09(水) 00:47:06

TCPで受信するときって、毎回受信サイズ違いますよね
それらを一つのデータとしてバッファに入れる方法ってあるのでしょうか？
recvで一度に受信できるサイズを1パケット以下にすればいいのでしょうか？

692 ：デフォルトの名無しさん：2009/09/09(水) 00:50:13

recv1とrecv2をそれぞれ別のスレッドで待ち受けているとき、

recv1→recv2　もしくは、recv2→recv1　の順番に処理されますよね

それを、recv1→　と同時に処理させることは可能なのでしょうか？
recv2→

前者だと見かけ上は、同時にやろうとしてるけど、順番で処理していくのですが
後者だと処理速度は半分程に落ちるけど同タイミングにきても同じスピードで処理していくみたいに

これって、プログラムだけで組めますか？

693 ：デフォルトの名無しさん：2009/09/09(水) 01:44:02

>>691
> TCPで受信するときって、毎回受信サイズ違いますよね
> それらを一つのデータとしてバッファに入れる方法ってあるのでしょうか？
recvで受けたデータを順番にバッファに詰めていけばいいだけだろ。
ネットワークプログラミング以前のスキル不足じゃね？

694 ：デフォルトの名無しさん：2009/09/09(水) 01:49:13

>>692
たぶん何をやりたいのか自分でもわかってないのが問題だとおもうけど。

TCPなら、それぞれのソケットから交互に1byteずつreadしていけばいいんじゃね？

695 ：デフォルトの名無しさん：2009/09/09(水) 01:54:46

できる限り、見かけ上の並列じゃなくて完全に近い並列をしたいとおもったのですが
ＣＰＵが2個あるようなイメージの処理で
そういうのってやはり無理なのかなぁ。

そうでないと、送信と受信を同タイミングでする際、どちらかが終わってからじゃないと
処理できませんよね。送信→受信もしくは、受信→送信の流れに

696 ：デフォルトの名無しさん：2009/09/09(水) 03:51:51

まず、ネットワークプログラミング以前にその完全に近い並列を実現させろ。
あとはソケットからの読み込みとかを組み込めば楽勝。

697 ：デフォルトの名無しさん：2009/09/09(水) 10:10:04

cではwinsockを使っていたのですが、
最近javaでネットワークプログラミングを始めようと思っています。(TCP)
cのときは、ここの話題にも時々出てくるように長さプレフィックスつけたり、区切り文字使ったりとても苦労しましたが、
javaだと、Serializable、ObjectInputStreamといったものでオブジェクト渡せば悲しいぐらい簡単で、うまくいっているように見えます。
これは正解ですか？

698 ：デフォルトの名無しさん：2009/09/09(水) 10:18:57

>>697
パフォーマンスとか効率とかを求めないなら、便利で楽で良いと思うよ

699 ：デフォルトの名無しさん：2009/09/09(水) 10:40:09

>>691
fdopenしてstdioにバッファリングさせる。

700 ：デフォルトの名無しさん：2009/09/09(水) 10:57:11

>>695
CPUが2つあってもネットワークインタフェースがひとつじゃあねぇ。

701 ：デフォルトの名無しさん：2009/09/09(水) 10:58:49

ストリーム系のクラスで取得するにも区切り識別は必要だろ？

702 ：デフォルトの名無しさん：2009/09/09(水) 11:06:08

必要だけど、それが何か?
>>691には関しての質問はないので、解決済みなんだろ。

703 ：デフォルトの名無しさん：2009/09/09(水) 11:12:08

>>697
> 悲しいぐらい簡単

ﾜﾛﾀ

しかし C でも TLV とかにしてればさして苦労はしなかっ
たはずだぞ。マクロでなんとかなってた気がする。

704 ：デフォルトの名無しさん：2009/09/09(水) 11:37:44

>>697
あと、Java以外のシステムと通信しないなら。

705 ：デフォルトの名無しさん：2009/09/09(水) 11:46:30

>>702
話がかみ合ってないぞ

706 ：デフォルトの名無しさん：2009/09/09(水) 22:00:17

クライアントからＩＥ以外でアクセスされたらクライアントのＩＥ強制起動してやりたいんだけど
ＡｃｔｉｖｅＸ無しでできる？

707 ：デフォルトの名無しさん：2009/09/09(水) 22:27:18

無理
例えばtelnetとかでアクセスすることも可能なわけで
telnetはサーバから何を受け取ってもIEを起動したりしないし

708 ：デフォルトの名無しさん：2009/09/09(水) 22:33:24

　　　　　 |
　　＼　　__　　／
　　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　　　　　|ミ|
　　／　｀´　＼
　　　　　('A`)　　　　　IEを強制起動するtelnetを
　　　　　ノヽノヽ　　　　あらかじめ配布しておけば！
　　　　　　　くく

709 ：デフォルトの名無しさん：2009/09/09(水) 22:34:09

　　　　　('A`)　　
　　　　　ノヽノヽ＝３　ブー
　　　　　　　くく

710 ：デフォルトの名無しさん：2009/09/09(水) 22:44:50

>>698 >>704
ありがと、サーバーもjavaで書くんで大丈夫そうです
パフォーマンスは気にならないわけではないが・・・まぁいっかｗ

>>703
TLVとか詳しくわからない・・・
まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてたが、
マクロとか使えるものが合ったのか・・・・

711 ：デフォルトの名無しさん：2009/09/09(水) 23:02:10

マルチキャストアドレスで送ることはできるのですが何故か受信されません
ブロードキャストで送ると受信はされるのですが…
送信に関しては設定はいらないけど受信する場合は何か設定がいるのでしょうか？

712 ：デフォルトの名無しさん：2009/09/10(木) 10:08:35

受信したいマルチキャストアドレスに参加しなければならないんじゃなかったっけ

713 ：デフォルトの名無しさん：2009/09/10(木) 11:15:43

>>706
一種のウィルスだな、それは。

714 ：デフォルトの名無しさん：2009/09/10(木) 22:16:06

>>706
できるわけねーだろクソガキ消えろ

715 ：デフォルトの名無しさん：2009/09/10(木) 23:06:52

何をファビョってるんだ？

716 ：デフォルトの名無しさん：2009/09/10(木) 23:50:12

>>710
> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた

TLV は type, length, value だからそんなもん。
メリットとしては新旧バージョンが混在しても
TL の部分で読み飛ばし判定が出来るってことかな。

だから構造体みたいなのは構造体ごと読み飛ばせるように
中の要素サイズも含めたサイズを指定することになる。

717 ：デフォルトの名無しさん：2009/09/10(木) 23:57:31

>>712
マルチキャストアドレスグループの参加の方法ってどうやるのでしょうか？
送信側は参加に関係ないのかな

718 ：デフォルトの名無しさん：2009/09/11(金) 00:01:39

>>717
とっておきの解説サイトを教えてやろう。
http://www.google.com/

719 ：デフォルトの名無しさん：2009/09/11(金) 00:14:24

>>716
素人の知識で自慢するなかれ。笑われるよ。

720 ：デフォルトの名無しさん：2009/09/11(金) 01:08:46

>>719
国際通信規格でも使われてますが何か?(ﾌﾟ

721 ：デフォルトの名無しさん：2009/09/11(金) 01:15:14

>>720
その国際通信規格を>>679,710に勧める(自慢する)のが適切か？と言ってるだけ。
他の選択肢と比較した場合の利点と欠点を理解してるのか？

722 ：デフォルトの名無しさん：2009/09/11(金) 01:34:12

選択肢はあんまりないんじゃね？
・固定長
・区切りをつける（STX,ETXとか改行とかみたいな）
・ヘッダ＋ボディ構成（ヘッダ部に種別と長さみたいな）
くらいなもんじゃね？

TLV形式って名前は知らなくてもみんな無意識に
似たような実装してるだろ

723 ：デフォルトの名無しさん：2009/09/11(金) 02:03:59

選択肢をあげるなら、こうだろ。
・オブジェクトマーシャリング -- >>679,710が選んだ方式で、言語が限定される
・テキスト -- Internetプロトコルで多用される(SMTP/HTTPなど)
・プログラミング言語様式の定義言語 -- 現在の主流(Protocol Buffer/IDL/XDRなど)
・形式的仕様記述言語 -- TLV方式(国際通信規格の名称はASN.1/BER)
後にいくほど、メッセージ形式仕様定義の厳密さは増すが、実装は困難になる。

だから安易にTLV方式を採用することで「みんな無意識に似たような実装して」
似たようバグを作り込んでいる。もしもTLV方式に固執しつつ、他の方式と同等な
品質も確保するのなら、ASN.1インスタンスをBERへ変換するC言語モジュールを
自動生成できるASN.1コンパイラを導入するしかないが、覚悟と準備が前提になる。

これらの事柄を理解した上で、その国際通信規格とやらを提案(自慢)するのか？と
言っているのだが。自分は、>>679,710が彼自身の置かれている現状の中で、
最良な方式を(無意識にせよ)選択したと考えたから、特にレスもせずスルーしたよ。

724 ：デフォルトの名無しさん：2009/09/11(金) 02:35:38

>>723
似たようなバグってたとえばどんなの？

725 ：デフォルトの名無しさん：2009/09/11(金) 03:01:22

>>724
TLV方式というのは、XMLと同じで柔軟で階層的なデータ構造を実現できる(これは利点)。
ただし、それだけでは、スキーマを決めずに(定義せずに)XMLでデータ交換するようなものだから、
通信相手相互の解釈の違いがバグに直結する。

解釈の相違について、具体的な例をあげる。
・このTypeは必須か/オプションか
・これらのTypeの並び順は規定されるか/自由か
・このTypeの重複は許すか/禁止するか(列の表現)
・このTypeの列の要素は多相を許すか/禁止するか
これらのデータ構造(構文)を形式的に定義するのが、ASN.1という言語。
XMLでいうDTD/RELAX-NG/XML Schemaといったスキーマ定義言語に相当する。

おそらく、これらが問題になるほどの複雑なメッセージ形式は必要ねえだろ？と
思うかもしれない。だとすれば(それほど単純なメッセージ形式であるならば)、
それは他の3つの方式を選択すべきで、あえて柔軟なTLV方式を選ぶこと自体が誤りである、
という結論になる。

726 ：デフォルトの名無しさん：2009/09/11(金) 03:13:10

そこらの人間だって DB スキーマ設計くらいやるだろ。
それを通信路上でやるだけ。

727 ：デフォルトの名無しさん：2009/09/11(金) 03:33:15

>>726
DBスキーマは固定的(柔軟ではない)だよ。
通信であれば>>723の3番目にあげたProtocolBuffer/IDL/XDLに近い。
これなら、ある程度のプログラマなら対応できると思う。

ただ、ASN.1は(>>723で書いたように)、XMLスキーマに近い位置づけの言語。
そこらの人間だってDBスキーマくらいはやれるかもしれないけど、
XMLスキーマを自由に操れる人は、RDB屋さんほどありふれていないでそ。
XMLデータベースの普及を遅らせている、最大の要因だと思っているよ。

728 ：デフォルトの名無しさん：2009/09/11(金) 23:54:35

TLVとASN.1の関係が解らないんだけど。
単にTLVってType,Length,Valueの略ってわけじゃないの？w

729 ：デフォルトの名無しさん：2009/09/12(土) 00:08:50

Type,Length,Valueを全部埋め込んだデータ構造の意味で使ってるみたいだね。

730 ：デフォルトの名無しさん：2009/09/12(土) 00:43:05

TLVはType,Length,Valueの略。
一般的には、ネットワーク上を流れるバイナリ形式のデータ構造表現法の一つ。

で、そのエンコード/デコード処理は手作業で作成することもできるし、過去はそうだった。
ただ、(>>725であげたような)問題があるから、最初は(日本語のような)自然言語で
メッセージの仕様(エンコードの規則)を記述していた。そして自然言語では、
仕様の曖昧さが残るから、形式的な仕様記述法が考案され、最終的にOSIプレゼンテーション層仕様の
一つとして、ASN.1(Abstract Syntax Notation：抽象構文記法)という名前で国際規格化された。

で、ASN.1の仕様策定と同時に、ASN.1で定義されたメッセージ仕様をエンコードするための規則も
策定された。これがBER(Basic Encoding Rule：基本エンコーディング規則)。
BERの中身は、階層的なType,Length,Value構造になっている。

自分としては、>>720で国際通信規格という言葉が提示されたから、
ああ、それは一般的なTLV構造ではなく、ASN.1/BERの事を指しているんだなと解釈し、
それ以降は>>720の意向に沿った形でレスしているつもりだよ。

731 ：720：2009/09/12(土) 02:14:31

>>730
いや、全然沿ってない（w

どうも俺には ASN1 や XML ってパラノイア的に自由度
が高すぎるというか、レキシカルな部分とセマンティッ
クな部分がごっちゃになってるとういか、やれやれだぜ
とい印象を受ける。

TLV 的なもの、というのはレキシカルな意味で出したん
だよ。元々「シリアライズ」なんて言葉も出てたしオブ
ジェクトとの紐づけもそんなに難しくない。X というコ
ンポーネントがオプショナルに更に小さな a を持つ、
とかなら X の試験における a の有り無し評価くらいの
試験で済むじゃん。X が充分小さければ組合わせ数も
小さいし、X を含む試験では a の評価はオミット出来る。

ところが XML とかになるともう大変。あらゆる文脈で
X の a を評価しないといけなくなりそうなんだが皆どう
してんの? それとも皆そんなに巷のエンコーダ／デコー
ダ信用してんの?

俺が時流に乗ってないという意見は認める（w

732 ：デフォルトの名無しさん：2009/09/12(土) 02:58:30

>>731
ではナゼ>>716でTLVを提案し、>>720で国際通信規格という言葉を持ち出したの？
そんな「パラノイア的に自由度が高すぎるというか....」な物を初心者に自慢したのはナゼ？
それを何度も問いているんだけど、まるで返答がない。まあ、どうでもいいんだけどね...。

>TLV 的なもの、というのはレキシカルな意味で出したんだよ。

TLVのレキシカル(lexical：字句)には、必ずシンタックス(syntax：構文)が伴う。
言語処理系を知っているなら、それは常識だよね。
そのTLV(BER)のシンタックスに対応するのがASN.1。
TLVという「パラノイア的に自由度が高すぎるというか....」な物を提案する以上、
そのシンタックスも一緒に考えないと、システム設計が崩壊するよ。

>皆どうしてんの? それとも皆そんなに巷のエンコーダ／デコーダ信用してんの?

今のネットあるいはビジネス分野では、SOAPやXML-RPCといったXMLベースの技術が主流だよ。
特にアプリケーションに近い開発者には、XMLとXMLスキーマは避けて通れない技術になりつつある。

ネットワークに近い開発者(たとえば、このスレ住人の大半であろうソケットプログラマ)であれば、
>>723の3番目にあげたProtocolBuffer/IDL/XDRが主流であると思う。ただし、実際の実装は、
手作業でデコーダ/エンコーダを作成することが大半。メッセージ形式が単純なうちは、それで十分。

もし、それが負担になるようなら、専用のコンパイラ(ソースコードジェネレータ)の導入を検討すべき。
ProtocolBuffer/IDL/XDRのどれもがプログラミング言語に近い様式でメッセージ形式を記述できるから、
多くのプログラマが活用できると思う。ただ、新しい技術の導入には、必ず壁がつきまとうから、
生産性や品質保証といった項目を十分に比較/検討してから、導入の是非を判断してください。

733 ：720：2009/09/12(土) 03:05:07

>>732
> ではナゼ>>716でTLVを提案し、>>720で国際通信規格という言葉を持ち出したの？

TLV は国際通信規格でも使われてるし、もっとお手軽に
使える考え方でもあるでしょ。実際 >>710 だって独自に

> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた

って言ってるんだし。

そこに「そんなの教えてどうすんの」的なのを言いだす
方が「説教したいだけなんですね?」って思うけど。

734 ：デフォルトの名無しさん：2009/09/12(土) 04:11:50

>>733
>TLV は国際通信規格でも使われてるし、もっとお手軽に
>使える考え方でもあるでしょ。

その「国際通信規格」という甘い言葉にのせられ、一見すると「もっともお手軽に使える考え方」に
思える「TLV方式の実体」というのが、ASN.1という「パラノイア的に自由度が高すぎる(>>731)」
枠組みで固めなければ容易に扱えない「怪物」であるという事を、気がついてくれないのかな....orz

>実際 >>710 だって独自に
>> まぁ何送るか教えて、(サイズ教えて)、データ送るようにはしてた
>って言ってるんだし。

>>710が言ったのは、単純に<長さ, 固定長ヘッダ(複数フィールド), 可変長ボディ(単一)>という
メッセージ形式ではないのかな。これはTLV方式じゃないよね。Typeフィールドが無いから。

このくらい単純なメッセージ形式であれば、(怪物である)TLV(あるいはXML)を採用しなくても、
ProtocolBuffer/IDL/XDRが使えるよ。どれも構造体/共用体/可変長文字列/可変長配列が定義できるし、
>>716にあった新旧バージョンの混在は、共用体で容易に実現できる。

返答してくれたから、>>720の意図は理解できた。説教臭いと感じているようだし、
後ろ向きな問いかけであるのは事実だから、これ以降は提案うんぬんの話は持ちかけない。
これで終わりにするよ。

735 ：デフォルトの名無しさん：2009/09/12(土) 09:01:20

受信バッファに溜まってるデータサイズの取得ってどうやるの？Winsockで

736 ：デフォルトの名無しさん：2009/09/12(土) 11:48:28

>>735
実際に受信してみればわかる
ioctlsocketとかでもわかるけど、それをやる前にザ・間違いリストの12番を読むべき
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/articles/lame-list.html#item12

737 ：デフォルトの名無しさん：2009/09/12(土) 12:35:45

しかも取得した直後に増えてるかも知れないし。

738 ：デフォルトの名無しさん：2009/09/12(土) 13:25:09

>>736, 737
元の質問は, 全部到着したかどうかを判定したいって書いてないんだが…

おれは, バッファをどれだけ増やせばいいかを調べるときには ioctlsocket
を使うけどな

739 ：デフォルトの名無しさん：2009/09/12(土) 15:41:51

マルチキャストアドレスグループの参加の方法ってどうやるのでしょうか？
送信側は参加に関係ないのかな

740 ：デフォルトの名無しさん：2009/09/12(土) 17:18:10

>>739
とっておきの解説サイトを教えてやろう。
http://www.google.com/

741 ：デフォルトの名無しさん：2009/09/12(土) 17:27:06

つまんね

742 ：デフォルトの名無しさん：2009/09/12(土) 20:39:13

>>740
くだらない。ひねりがない。

743 ：デフォルトの名無しさん：2009/09/12(土) 21:00:31

ひねる必要無いでしょ。>>717-718

744 ：デフォルトの名無しさん：2009/09/12(土) 21:21:05

そこで一捻り欲しかったって話だろ

745 ：デフォルトの名無しさん：2009/09/12(土) 21:23:01

ひねったら、馬鹿には理解できないかもしれないじゃないか。

746 ：デフォルトの名無しさん：2009/09/12(土) 21:27:11

>>717-718
>>739-740
次回用テンプレおいときますね

マルチキャストアドレスグループの参加の方法ってどうやるのでしょうか？
送信側は参加に関係ないのかな

とっておきの解説サイトを教えてやろう。
http://www.google.com/

747 ：デフォルトの名無しさん：2009/09/12(土) 21:36:49

自演乙

748 ：デフォルトの名無しさん：2009/09/12(土) 21:39:35

なんかおもしろいのかこれ？

749 ：デフォルトの名無しさん：2009/09/12(土) 22:09:23

>>739
setsockopt で IP_ADD_MEMBERSHIP を設定するんじゃねぇの?

750 ：デフォルトの名無しさん：2009/09/12(土) 22:16:26

あるアプリ（サーバー・独自プロトコル）のソースコードを見ていたのですが、
・非ブロッキング
・acceptはSleepとセットのループ
・送受信はwrite(const void *p, int len)のようなラップ関数内で、recv/sendとselect（待つのは一つのソケットのみ）によるループ
により実装されていました。
※何れも一つのソケット（コネクション？）に対し一つのスレッドを生成し処理していました。
この場合、ブロッキングと比べてどのようなメリットがありますでしょうか？
私の無い頭だと、ブロッキングとあまり変わらないように思ってしまいまして・・・

751 ：デフォルトの名無しさん：2009/09/12(土) 22:59:49

>>740
なにか質問があったら「ググレ」って得意げに言うのやめてもらえます？
こっちは別にあんたらみたいに教える気などなく説教したがりなだけの人に無理に聞こうと思ってませんよ。
私は、グーグルさんじゃなくて、ここで聞いているんです。
自分で調べる気がないのはなく、ここでもし知ってる人がいたら教えてもらおうという選択肢を選んだだけのこと。
教える気ないなら黙ってもらってて結構。
この掲示板の管理人さんに「質問はしないでください」といわれるのなら質問は自粛しますが
質問の制約のない掲示板で、管理人でもない分際の人に「自分で調べなさい」などと言われる筋合いはありません。

752 ：デフォルトの名無しさん：2009/09/12(土) 23:02:37

>>751 他の質問者の邪魔

753 ：デフォルトの名無しさん：2009/09/12(土) 23:04:00

>>738
バッファを動的に増減するメリットは何？

754 ：デフォルトの名無しさん：2009/09/12(土) 23:11:54

>>739はググれといわれてもしかたないね。
「UDPで複数の端末にパケット投げたりできますか？」
という質問なら親切に答えたかもしれないけど。

755 ：デフォルトの名無しさん：2009/09/12(土) 23:21:46

別に良いよ答えないで

756 ：デフォルトの名無しさん：2009/09/12(土) 23:28:25

回答者に不快な思いをさせると質問者は損する (回答を貰えなくなるかもしれない)
質問者に不快な思いをさせても回答者は損しない
従って回答者は何書いてもどうってことないが、質問者は書く内容をよく考えるべき

757 ：デフォルトの名無しさん：2009/09/12(土) 23:34:00

不快な思いをすると損してんじゃないの？

758 ：デフォルトの名無しさん：2009/09/12(土) 23:39:04

質問者のふりして回答者をイラつかせるような書き込みをする荒らしが
最近いるようなのでもちつけ。

759 ：デフォルトの名無しさん：2009/09/12(土) 23:40:16

ブロッキングと非ブロッキングの違いってなんですか

760 ：デフォルトの名無しさん：2009/09/12(土) 23:40:53

ブロッケンとブロッケンＪｒの違いくらいはさすがにググれ

761 ：デフォルトの名無しさん：2009/09/12(土) 23:41:06

不快な思いを「させると」

762 ：デフォルトの名無しさん：2009/09/12(土) 23:41:53

？

763 ：デフォルトの名無しさん：2009/09/12(土) 23:42:03

>>759
ブロックするか、ブロックしないか

764 ：デフォルトの名無しさん：2009/09/12(土) 23:49:44

>>750
=== マルチスレッド＆ブロッキング方式 ====
<利点>
・プログラムのロジックが単純になる。一般的なCプログラムが標準入力からのreadと
　標準出力へのwriteをループさせて処理しているように、ソケットとのreceive/sendを
　ループさせることで処理を実現できる。
・上記の理由により、TCPはレコード境界が無いプロトコルであるにもかかわらず、
　receiveで待ち続ければいいから、受信メッセージの組立て処理のロジックは単純になる。
・マルチコア/マルチプロセッサ構成ではスレッド単位にコアまたはCPUが割り当てられるから、
　コア数/プロセッサ数に応じてシステムの性能がスケーラブルに向上しやすい。
<欠点>
・スレッド間で資源の競合がある場合(たとえば同じ変数/ファイルを複数のスレッドが共有する場合)、
　スレッド間で排他制御が必要になる。一般に、排他制御のデバッグは再現性が無いために難しい。

=== シングルスレッド＆非ブロッキング方式 ====
<利点>
・そもそもスレッド間の資源競合が存在しないため、デバッグが容易になる。
<欠点>
・プログラムのロジックが複雑になる。TCPコネクション単位にオブジェクトを管理する(Cであれば、
　たとえば構造体で送受信バッファ等を表現し、それらをリンクリストで繋いで管理する)必要がある。
・TCPはレコード境界の無いプロトコルであるため、ソケットに届いた受信メッセージの断片を
　少しずつ組立て、さらにその処理を各TCPコネクション上で並行に実行させる必要があるため、
　プログラムのロジックが複雑になる。
・マルチコア/マルチプロセッサ構成ではコアまたはCPUへの割り当てはコンパイラの最適化に
　依存するから、コア数/プロセッサ数を増やしていっても、期待したほどシステムの性能は向上しない。

他にもあれば(訂正を含めて)追加ヨロ >>all

765 ：デフォルトの名無しさん：2009/09/13(日) 00:02:20

通信初心者ですがよろしくお願いします。
プロセス間通信をしたいんですけど、
サーバーは同一のパソコン上で一つのみしか
起動できないんでしょうか？
複数サーバーがあるとクライアントがどのサーバーにつなげば良いのかわからないのでは？
と思うのですが。
それとも、サーバーのアドレスはそれぞれ異なるように設定できて
そういう問題は起こらないんでしょうか？
よろしくお願いします。

766 ：デフォルトの名無しさん：2009/09/13(日) 00:07:43

>>751
クズ質問者に文句付けるのがオレの流儀。
管理人に「クズ質問者に文句付けるな」と言われたら自粛するが、
制約の無い掲示板で、管理人でも無い分際のクズに「ググれ言うな」と
言われる筋合いは無い。

嫌なら来るな。

767 ：本当に”管理”者です：2009/09/13(日) 00:10:54

>>766
ググれ言うな。

768 ：デフォルトの名無しさん：2009/09/13(日) 00:14:05

>>765
ポート番号というもので区別できるようになっている
サーバの待機するポート番号とクライアントの接続先のポート番号が一致したものが接続される
HTTPは80番、FTPは21番、のように、サーバの種類ごとにあらかじめ決まっている
同じポート番号でサーバを2つ起動することは出来ないので、その場合は番号をずらすなりなんなり調整する

769 ：デフォルトの名無しさん：2009/09/13(日) 00:14:46

>>767
消えろ。カス。

770 ：デフォルトの名無しさん：2009/09/13(日) 00:16:12

>>753
ごく稀なケースだけど, 俺は,
各データのサイズが結構巨大な可変長のデータで頭にデータ長がない
場合に使う

771 ：デフォルトの名無しさん：2009/09/13(日) 00:16:44

>>768
なるほどー。ポート番号で区別するんですね。
設定の仕方とか調べてみます。

772 ：デフォルトの名無しさん：2009/09/13(日) 00:23:39

>>770
それすると何が嬉しいんだ? パフォーマンスには影響無さそうに思う。

773 ：デフォルトの名無しさん：2009/09/13(日) 00:24:43

教えねーよバーカｗｗｗｗｗｗｗｗｗｗｗ

774 ：デフォルトの名無しさん：2009/09/13(日) 00:26:12

socketのポート番号とどう違うのですか？

775 ：デフォルトの名無しさん：2009/09/13(日) 00:26:13

もうそろそろこのスレの削除依頼出してきてもいいだろう

776 ：デフォルトの名無しさん：2009/09/13(日) 00:32:38

>>774
何とsocketのポート番号との違いを知りたいの？

777 ：デフォルトの名無しさん：2009/09/13(日) 00:37:57

クズ質問者が粘着荒らしになるのはありふれた現象。

778 ：デフォルトの名無しさん：2009/09/13(日) 00:50:42

>>770
mallocして一回?のrecvで受信するのと固定長バッファで複数回recvするのと
どちらが効率が良いかって話になりますね。
固定長バッファのサイズにもよるけど>>772さんの言われるようにたいして
パフォーマンスは変わらない気がする。

779 ：デフォルトの名無しさん：2009/09/13(日) 00:54:16

>>774
socketにポート番号はない。
ポート番号はUDPやTCPに対してある。

780 ：デフォルトの名無しさん：2009/09/13(日) 01:54:14

>>764
おぉありがとうございます。
でもこのアプリはマルチスレッド＆非ブロッキングなんですよ。
一つのスレッドは一つのソケットしか操作しないのでブロッキングでもいいような気がするんですが。
メリットがあるとすれば、スレッド（送受信）の停止等を楽にコントロール出来るってところでしょうか？
っと思いましたがSleepやselectでの待機処理があるので一緒な気もします。

しかし本当の意味?での非ブロッキングはすごく複雑そうですね・・・

781 ：デフォルトの名無しさん：2009/09/13(日) 04:02:41

>>780
一回は無理してでもシングルスレッドで書いとくと
後の人生で応用が利くからお勧め

782 ：デフォルトの名無しさん：2009/09/13(日) 05:25:36

UDPやTCPはsocketではないのですか？

783 ：デフォルトの名無しさん：2009/09/13(日) 09:28:28

>>764
selectはコネクション数が非常に多い場合に非効率的になる。

>>782
UDPやTCPはプロトコルです、socketではありません。

784 ：デフォルトの名無しさん：2009/09/13(日) 18:45:45

>>783
thx!

785 ：デフォルトの名無しさん：2009/09/13(日) 18:50:10

スレッドってどれくらい作れるの？
１万個くらいつくれるの？

786 ：デフォルトの名無しさん：2009/09/13(日) 19:27:46

大抵は、アドレス空間の大きさと、各スレッド毎の使用スタック量に左右される。
他にも制限あるだろうけどね。

787 ：764：2009/09/13(日) 19:28:48

>>780
>でもこのアプリはマルチスレッド＆非ブロッキングなんですよ。

>>764に挙げたのはselectによるタイマ監視を使用しない、一般的なケースですね。
もし>>750のようにタイマ監視が前提であれば、receiveによるプロセスのブロックは
selectによる監視の妨げになりますから、非ブロッキングなreceiveを使います。
ソケットは1個でも、そのデータ受信イベントとタイムアウト発生イベントを
同時に待ち受けるわけですから、selectの利用は自然な発想だと思います。

あと>>750で気になったのは、acceptをSleepとのループで待っているとの記述です。
acceptも(receiveと同じように)TCPコネクション確立通知イベント発生をタイムアウト付きで
selectを用いて監視できます。Sleepというのが何なのか分かりませんが(おそらくは独自の
マクロかライブラリ関数？)、C標準ライブラリのsleep関数に相当ものであると仮定すれば、
sleepによる待ち時間は無駄ですから、TCPコネクション確立通知に対する応答時間を
遅延させるだけの意味しか持たないように思えます。だから一般的にはタイムアウト付きの
selectでacceptをループさせます。謎のSleepについて、調査する必要があるかもしれません。

(長いので続く)

788 ：764：2009/09/13(日) 19:34:47

(787の続き)

>しかし本当の意味?での非ブロッキングはすごく複雑そうですね・・・

非ブロッキング処理を一般的に書くと>>764のようになって難解に見えますが、
その実装方法は「イベント駆動プログラミング」です。GUIアプリ開発では一般的ですよね。
普通の対話型Cプログラムだとscanf/printfのループで処理しますが、イベント駆動なGUIだと、
まずイベント待ちループに入り、マウスクリック/キー押下イベントが発生すると、事前に
登録しておいたアクションが実行され、そのアクションの中でウィジェットを操作します。

ネットワークプログラムにおけるイベント駆動プログラミングも同様に、イベント待ちループ内の
selectでTCPコネクション確立通知/データ受信(複数)/タイムアウトといったイベントの発生を
同時に待ち受け、イベントが発生すると対応するアクションを実行し、そのアクションの中で
独自プロトコルを実装した有限状態機械(Finite State Machine)へ発生イベントを送ります。

何度か開発経験を重ね、慣れてくるとイベント駆動処理を独自のライブラリ関数として
設計できるようになると思います。またGUIアプリ開発でも考え方は同じですから、
その本質を理解できれば、Webブラウザやメーラのようなネットワーク対応GUIアプリも、
自分で一から開発できるようになる訳で、(>>781が言うように)後の人生で応用が利きます。
大変ですが技術の習得をお勧めします。

789 ：デフォルトの名無しさん：2009/09/13(日) 19:37:05

＞acceptはSleepとセットのループ
Sleep(0)を呼び出しているんじゃないのか？
Sleepに与えている時間は何ミリ秒なんだ？>>780

790 ：デフォルトの名無しさん：2009/09/13(日) 20:29:14

通信を暗号化したいんだけど、一番ソース改変の少ない方法ってなんだろ
サーバもクライアントも自作なのでなんでもし放題です

791 ：デフォルトの名無しさん：2009/09/13(日) 20:42:54

>>790
ipsecとか、ssh port forwardとか。

792 ：デフォルトの名無しさん：2009/09/14(月) 00:00:25

>>787
レスありがとうございます。

同期recvのみでもデータ受信とタイムアウト発生を待機出来るような気がしますが、
やはりselectの方が良いのでしょうか？

sleepは>>789さんの仰る通り、Win32APIのSleepを呼び出しているようです。
接続が無い場合の無駄なループを減らすためか、100ms待機しています。
しかし>>787さんのselectを使う方が理にかなっていますね。
あと勘違いしてましたが、acceptの場合は非ブロッキングやselectのメリットって多いんですね。
というか同期acceptのみだと、停止（やるとすると無理矢理かWSACancelBlockingCallかな？）や受け入れ数制限とか出来ないんですね。

>>788
おかげさまで少しだけイメージが掴めてきたような気がします。
でもブロッキングに比べて、スレッドやメモリは節約できますが、コアが多くなるほど全体的なパフォーマンスが落ちるような気もします。
その場合はある程度接続が多くなると、スレッドを増やす感じなのかな？（イベントオブジェクトの場合は必然的にそういう実装になるようですが）

おもーい腰を上げて、もう少し他のP2Pあたりのソースコードでも読みつつ勉強しようと思います。。

793 ：764：2009/09/15(火) 01:09:01

>>792

スマン、自分はWinSockについてはまるで詳しくない。
勝手にUNIXソケットだと思い込んでレスしてた。

>同期recvのみでもデータ受信とタイムアウト発生を待機出来るような気がしますが、
>やはりselectの方が良いのでしょうか？

UNIXの場合は(シグナルを除いて)receiveではタイムアウト発生を待機できないから、
select使用が必須になる。WinSockが待機できるのなら、それで実装してもいいと思う。
自分なら(>>788で述べた)イベント待ちループ内で、すべてのイベント発生を待機させるけどね。
言い換えると、selectを使用して、イベント監視を1カ所に局所化した設計を選ぶ。

ただ、(>>783が指摘しているように)WinSockはselectのオーバヘッドが大きい。
だから、receiveで待機させる設計を選んだのかもしれない。自分に分かるのはここまで。
（UNIXであれば、それなりのリソースを用意することで、数10から数百TCPコネクションくらい
　までなら実用的な性能を実現できる。シングルプロセッサの時代には多用された手法です。）

>でもブロッキングに比べて、スレッドやメモリは節約できますが、
>コアが多くなるほど全体的なパフォーマンスが落ちるような気もします。

その通りだと思う。

今でもシングルスレッド＆非ブロックが多用されるのは、クライアントの開発。
GUIツールキットがあるから、マルチスレッディングが使いづらいのと、
性能や規模拡大性(スケーラビリティ)は、それほど重視されないのが理由。(Winnyが典型例かな？)
サーバ開発で採用されるのは、組み込み用途でリソースが極端に制限される場合が多い。
今時のサーバ開発では、(UNIXであっても)マルチスレッディングが一般に採用されるはず。

794 ：デフォルトの名無しさん：2009/09/15(火) 09:29:25

winsockについてですが、TCPサーバーで既に1つクライアントがacceptして接続しているとき、他のクライアントが接続してきても最初のクライアントがcloseするまで受け入れずに待機させたいときどうやれば良いですか？

795 ：デフォルトの名無しさん：2009/09/15(火) 10:22:15

最初のクライアントがcloseするまでacceptせずに放っておけばいいかと

796 ：デフォルトの名無しさん：2009/09/15(火) 16:30:18

>>793
マルチスレッドだと、スレッドからのプロセスのフォークが怖かったので
シングルスレッドでやることが多かったな。
今は怖くないから問題ないけど。

797 ：デフォルトの名無しさん：2009/09/15(火) 17:39:29

winsockで複数のクライアントから接続要求があったとき、サーバーで意図的な順番で並ばせる方法はありますか？
たとえば210.58.02.XX君は58.697.67.XXX君の後ろで・・・とか

798 ：デフォルトの名無しさん：2009/09/15(火) 17:45:27

待ち行列作って並ばせればいいだけじゃないの？

799 ：デフォルトの名無しさん：2009/09/15(火) 17:49:30

接続要求を受けるためにはacceptする以外の方法はない。
acceptする場合にクライアントの選択は出来ないので、不可能。

800 ：デフォルトの名無しさん：2009/09/15(火) 17:57:01

擬似的にやろうとすると
　接続要求は即accept　→　ｸﾗｲｱﾝﾄのIPをﾌﾟｰﾙ
　予定ｾｯｼｮﾝ数未満ならそのまま受け付け、予定ｾｯｼｮﾝ数いっぱいの場合には
　優先順位の低いｸﾗｲｱﾝﾄのIPかを判定して、そいつを切断
　ｸﾗｲｱﾝﾄ側は再接続をﾄﾗｲさせる
こういう管理になるんかねぇ

801 ：デフォルトの名無しさん：2009/09/15(火) 18:09:36

>>800
予定ｾｯｼｮﾝ数いっぱいの場合には、
acceptせずに放っておく方法(>>795)もあるね。

802 ：デフォルトの名無しさん：2009/09/15(火) 18:16:01

予定セッション数いっぱいでも、より優先度高い接続がきたら処理する必要があるのでは？

803 ：デフォルトの名無しさん：2009/09/15(火) 18:25:13

だから「擬似的(>>800)」なのでわ

804 ：デフォルトの名無しさん：2009/09/15(火) 18:28:13

そうそう　より優先度の高い接続を生かす為に
ｸﾗｲｱﾝﾄのIPをﾌﾟｰﾙ　って書いたつもりだったが言葉足らずだったかも

accept 直後の奴も　一旦ﾌﾟｰﾙの中に収めたうえで
「ﾌﾟｰﾙしたIP内で最も優先度の低い接続を切断しちゃおう」　という発想ね

805 ：デフォルトの名無しさん：2009/09/15(火) 18:30:39

なんか斧みたいなアプロダを作ろうとしてるみたいw

806 ：デフォルトの名無しさん：2009/09/15(火) 20:19:41

切断する場合には、いきなり切る(close)んじゃなくて、
その理由をメッセージとして送ってから切る(send&close)ほうがいいだろね。
だって、せっかく待ち行列に並んでマダカナ・マダカナーって待ってたのに、
後から来たヤローに割り込まれてキャンセルさせられるわけだから涙目になる。
きちんとクライアントに説明してあげたほうがいいと思われ。

あと最初の受け付けを拒否される場合も、理由の説明は必要だろうね。
普通はクライアントが時間を置いてリトライすれば、いつかは成功するんだろうけど、
何か障害が発生していて、何度リトライしても成功しない状況だってありえるから。

807 ：デフォルトの名無しさん：2009/09/15(火) 20:54:45

>>806
切断をする時点で明示的に切断されてるから
ある程度の説明責任は果たしてると思う。
なんか障害発生してたら接続された上で放置されたり
そもそも接続できないことがほとんどな気がする

808 ：デフォルトの名無しさん：2009/09/15(火) 21:52:03

無限ループrecvしてるときソフト終了させるとWSACleanupしてないってことになるのか？
変な挙動起こしたりするんかな

809 ：デフォルトの名無しさん：2009/09/15(火) 21:55:06

デバッグ中のプロセス止めるとか日常茶飯事だけど、変な挙動起こしたことは無いな。

810 ：デフォルトの名無しさん：2009/09/15(火) 22:03:30

>>805
斧は待ち行列じゃないよ
排卵と精子の関係だお

811 ：デフォルトの名無しさん：2009/09/15(火) 22:20:33

>>808
たぶんないな。
システムが割り当てたWSA系のリソース開放でしょ
だとすれば最悪メモリリーク起こすぐらいで挙動に大きな問題を抱えるものじゃないと思う。

812 ：デフォルトの名無しさん：2009/09/15(火) 23:35:31

>>798
どういう意味？

813 ：デフォルトの名無しさん：2009/09/16(水) 10:23:26

クライアントからサーバーに対してUDPパケットを送信した場合、サーバーはポートが解放されているから受信出来るとして
その後、サーバーからクライアントに返信した場合、クライアントアプリケーション側で受信できるのって

クライアントからサーバーに送信した地点で一時的にポート解放されてるから？
ファイアウォール等で受信拒否していてもつながるのも同じ理由なんだろうか

もしそうだとしたら、サーバーと通信中の２つのクライアントにお互いのIPとポートを教えて
お互いに何度かパケットを送信すれば何回目かで届き、
一度サーバーを経由するけど、そんな感じでP2Pネットワークを構築することってできる？

ためしにサンプルプログラムを組んでみたらうまくいったんだが、理論的にはどうなんだろう。
ルーターとかネットワーク環境によってはだめなんかな・・・

長文すまそ
あとスレチだったらすまそ

814 ：デフォルトの名無しさん：2009/09/16(水) 10:45:16

全然違うから。ファイアーウォール調べ直しな。

815 ：デフォルトの名無しさん：2009/09/16(水) 11:20:09

ああ、ファイアウォールはなかったことにしてくれ

816 ：デフォルトの名無しさん：2009/09/16(水) 12:29:54

なら、無かった事にして質問まとめなおせ。

817 ：デフォルトの名無しさん：2009/09/16(水) 12:46:42

>>813
セッションハイジャックとかしらべてみたらどうかな

818 ：デフォルトの名無しさん：2009/09/16(水) 13:05:00

>>817
サーバーとの接続は公開鍵方式で、その後クライアント同士の接続はサーバーが指定した
秘密鍵で行う予定なのでその辺は問題ない…と思う

セキュリティー云々は置いといて、ファイアウォールはアプリケーション許可してもらう前提で
これで一般家庭でつながらないことは無いのかな？と思ったまでです

819 ：デフォルトの名無しさん：2009/09/16(水) 16:04:15

winsockいじるようになってから画面右下のインターネットのアイコンが光りっぱなしになったんですがどうしてですか？

820 ：デフォルトの名無しさん：2009/09/16(水) 16:05:20

気のせいです

821 ：デフォルトの名無しさん：2009/09/16(水) 16:08:25

そこを何とかお願いします・・・
何か垂れ流してるみたいで気持ちが悪い

822 ：デフォルトの名無しさん：2009/09/16(水) 16:20:02

バカか？

823 ：デフォルトの名無しさん：2009/09/16(水) 16:23:26

バカですお願いします

824 ：デフォルトの名無しさん：2009/09/16(水) 16:31:09

1.winsockが本気出した
2.液晶画面の局所的なフレネル反射の本気
3.819が光過敏性てんかんになった
4.ソケットを開いたプロセスが終了しきれずに生きている
5.知らね

825 ：デフォルトの名無しさん：2009/09/16(水) 16:34:40

再起動してネット接続してもすぐに症状が出ます・・・

826 ：デフォルトの名無しさん：2009/09/16(水) 16:37:46

6. 実は前から光りっぱなしだったが、これまでは気にしていなかった

827 ：デフォルトの名無しさん：2009/09/16(水) 16:40:41

いえ、4日前からです。送信40kbps/受信4kbps位

828 ：デフォルトの名無しさん：2009/09/16(水) 16:54:18

7.気になるならパケットをキャプチャすればいーじゃん

829 ：デフォルトの名無しさん：2009/09/16(水) 20:00:09

バカさ加減酷すぎワロタｗｗｗ
Wiresharkも回せないのか？

830 ：デフォルトの名無しさん：2009/09/17(木) 09:07:17

俺的には「インターネットのアイコン」てのが気に入った。
なんでそういう単語を照れもなく使っちゃうレベルの人が
Winsock なんかに手ぇ出すかなあ。

831 ：デフォルトの名無しさん：2009/09/17(木) 18:38:25

いつの間にか1Gbpsで繋がるようになった

832 ：デフォルトの名無しさん：2009/09/17(木) 20:38:44

クライアントがInternets Explorerなんだけど
こいつにレスポンスコード302返したらどうなるん？

833 ：デフォルトの名無しさん：2009/09/17(木) 21:03:23

期待通りに動く。

834 ：デフォルトの名無しさん：2009/09/17(木) 21:36:18

IEの場合クッキー情報は一時的にTemporary Internet Filesフォルダにあると思ったのですが
セッションクッキー情報はTemporary Internet Filesに作られないのでせうか？

835 ：デフォルトの名無しさん：2009/09/17(木) 21:49:58

あるだろ。

836 ：デフォルトの名無しさん：2009/09/17(木) 22:40:05

セッションクッキーは永続的である必要が無いからファイルに持つ必要無いだろ。

837 ：デフォルトの名無しさん：2009/09/18(金) 03:01:40

Firefoxだと作られるよ

838 ：デフォルトの名無しさん：2009/09/18(金) 15:55:07

winsockについて質問です。

サーバープログラムに、クライアント数制限をつけたいと思っています。
例えば、10人までしか接続が確立できない。という類です。

FD_ACCEPTが呼ばれた際、acceptをします。
定員を超えていたら、次の行でacceptから帰ってきたSOCKET（正常なもの）をshutdownし、closesocketしました。
そうしたところ、どうやらクライアントに切断したことが伝わらないようで、クライアントのrecvがSOCKET_ERRORを返してくれません。

FD_ACCEPTを抜けた後、別の場所（メインループなど）でshutdown & closesocketした場合は伝わるようです。

・FD_ACCEPT内でclosesocketしてはダメなのでしょうか？
・そもそも上限に達していたら、acceptしないという方法はないのでしょうか？

ご教示よろしくお願いいたします

839 ：デフォルトの名無しさん：2009/09/18(金) 16:20:07

・recvは0を返してるんじゃない？
・recvが0を返したら、通信終了でいいんじゃない？

> ・そもそも上限に達していたら、acceptしないという方法はないのでしょうか？
それぞれのクライアントに対する処理は非同期で動作してる前提で話すけど、
acceptする前に、セマフォとかで調停する。

840 ：デフォルトの名無しさん：2009/09/18(金) 16:35:28

>>839
お返事ありがとうございます。なるほど。SOCKET_ERRORではなく、recvの返り値が0の場合も切断なのですね。
調べてみたところ、recvが0を返すのは「正常な終了」が行われた時とありました。
どうもありがとうございます。

841 ：デフォルトの名無しさん：2009/09/18(金) 16:40:43

>>839
aaceptする前に既にクライアントには受理されたことになってしまうので
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-3.html#ss3.3
acceptする前に調停しても、クライアントには伝わらないんじゃないかな。

acceptしないだけだと、たぶんクライアント側をしばらく待たせることになるので
それよりは一旦acceptだけしてから切断するほうが親切じゃないかな。

842 ：デフォルトの名無しさん：2009/09/18(金) 17:07:45

>>841
ありがとうございます。
最初から拒否しておく。ということはできないのですね。
意外でした。

・FD_ACCEPTの中で切断しても大丈夫
・上記の結果、クライアント側のrecvの返り値が0になる
のが確認できました。

843 ：デフォルトの名無しさん：2009/09/20(日) 19:01:52

listenって接続くるまで実行が停止状態になるんだよね？
既に接続が確立されてる相手からの送信データを待ちつつ
新たな接続が無いかどうかチェックするにはどうしたらいいの？

844 ：デフォルトの名無しさん：2009/09/20(日) 19:47:02

listenはすぐ戻るやろ、接続がクルまでブロックされるのはaccept

acceptでブロックされたくないなら
該当descriptorをselect/pollすりゃいい

845 ：デフォルトの名無しさん：2009/09/20(日) 19:47:03

C/C++でのソケットだと仮定して答えると、

接続待ちになるのはacceptね。

> 既に接続が確立されてる相手からの送信データを待ちつつ
> 新たな接続が無いかどうかチェックするにはどうしたらいいの？
接続が確立した相手用に新しいスレッド起こすか、
select使って複数のソケットに対してデータ待ちするか。
Windowsなら他の方法もあったかもしれない。

846 ：デフォルトの名無しさん：2009/09/20(日) 19:47:20

素人でしゃばんな

847 ：デフォルトの名無しさん：2009/09/20(日) 20:06:14

>>844
select/pollのとこでフリーズしてしまいましたが。。

848 ：デフォルトの名無しさん：2009/09/20(日) 20:30:14

>>846
別に>>844,845は、特に変な事は言っていないと思うけどな。

>>845に細かすぎる指摘(改善)すると、以下のようになるけど。

>select使って複数のソケットに対してデータ待ちするか。
　==>select使って複数のソケットに対してデータ受信と接続を同時に待つか。

文句付けるなら、自分ならこうだ！ってのをレスしたほうがいいと思われ。

849 ：デフォルトの名無しさん：2009/09/20(日) 20:30:42

>>848
素人でしゃばんな

850 ：デフォルトの名無しさん：2009/09/20(日) 21:15:37

>>847
それは使い方が悪いからだろう。たぶん。

851 ：デフォルトの名無しさん：2009/09/21(月) 02:17:11

>>849
夏厨は土に返ったはずであるが？
にーとさんかな？

852 ：デフォルトの名無しさん：2009/09/21(月) 07:09:59

なにファビョってるんだ？

853 ：デフォルトの名無しさん：2009/09/21(月) 12:58:08

馬鹿にはソケットは無理。

854 ：デフォルトの名無しさん：2009/09/21(月) 14:22:25

馬鹿にも使える(ばかちょんで高パフォーマンス)ソケットというか、ネットワークライブラリ欲しいけど、
言語とかトラフィックパターン依存になるから、
プリミティブなソケット以上の共通化は不可能なのかね。
スレッドプールの共通インターフェイスが先か。

855 ：デフォルトの名無しさん：2009/09/21(月) 15:57:50

大学はまだ夏休みだぜ

856 ：デフォルトの名無しさん：2009/09/21(月) 16:24:00

>>847
俺のとこじゃフリーズしなかった

857 ：デフォルトの名無しさん：2009/09/21(月) 18:27:22

>>856
select/pollのとこで止まってしまって先に進まなくなるのです。

858 ：デフォルトの名無しさん：2009/09/21(月) 19:13:01

accept可能になるのってreadableだったかwritableだったか忘れた・・・

859 ：デフォルトの名無しさん：2009/09/21(月) 19:19:50

readable

860 ：デフォルトの名無しさん：2009/09/21(月) 21:17:27

クライアント側のconnectはwritableだっけ

861 ：デフォルトの名無しさん：2009/09/21(月) 22:26:20

>>854
どこまでライブラリに機能を提供させるかという、境界線を引くのが難しい気がする。
トラフィックパターンが一方向の要求/応答に限定できるならRPC(JavaならRMI?)あるいは
HTTPライブラリで済むけど、わざわざソケットに手を出すのは、それ以外のパターンが
必要になる、ある程度複雑な(高機能な)アプリケーションを開発するケースだと思う。
ただ、そうなると、メッセージの衝突/送信権、分割/連結、優先制御/流量制御なども、
ライブラリが提供すべき機能要素として要求される(要求する人もいる)だろう。
またマルチスレッド/マルチプロセス/ファイバに関しても、どこまでライブラリで
対応させるべきか、人によって意見は分かれるはず。

だから、最終的には必要最低条件を満たしたソケットで落ち着いてしまうのだと思う。
個人的にはレコード指向(TCPのメッセージ境界対応)で全二重な機能だけを提供し、
あとは上位レイヤのプロトコル(アプリケーション)の実装にまかせる、軽いライブラリが
あってもよさげだと思うんだけどね。

862 ：デフォルトの名無しさん：2009/09/22(火) 15:55:58

>>857
よかったね。
コード見せてくれないとわからんがな

863 ：デフォルトの名無しさん：2009/09/23(水) 16:30:48

相手がcloseしたかどうか知るには？

864 ：デフォルトの名無しさん：2009/09/23(水) 16:35:36

>>863
「readして読んだバイト数が0の場合」ってのじゃなくて、なんかのひっかけ？

865 ：デフォルトの名無しさん：2009/09/23(水) 16:35:44

recvが0を返すかどうかを見る

866 ：デフォルトの名無しさん：2009/09/23(水) 16:51:05

recvがエラーを返した場合も

867 ：デフォルトの名無しさん：2009/09/23(水) 16:55:47

>>866 状況によるだろ?
Unix 系の EBADF, ENOTCONN, EINTR, EFAULT は
相手がクローズするしないに関わらず発生する

868 ：デフォルトの名無しさん：2009/09/23(水) 19:07:23

>>867
EINTR以外はプログラムバグじゃないの？

869 ：デフォルトの名無しさん：2009/09/23(水) 19:24:59

>>868
そうだけど、そんなん言ったらECONNRESETだけじゃないか
明示的にエラーになってクローズされてるのは

870 ：デフォルトの名無しさん：2009/09/23(水) 21:32:37

>>869
ですな～
でも、recvが想定外なエラーを返した時点でそのソケットは捨てるしかないけど。

871 ：デフォルトの名無しさん：2009/09/24(木) 14:51:00

一つのUDP同期ソケットで、スレッドAではrecv待機しスレッドBではsendするのって危ない？

一つのソケットでrecvとsendしたい場合はやっぱり非同期にするしかないのか・・・

872 ：デフォルトの名無しさん：2009/09/24(木) 15:23:51

>>871
危なくはないと思うが。shutdown/closeさえ気をつければ。
ただ、recvとsendを別スレッドにすると、スレッド間でデータの共有が
必要になって面倒だから、普通はシングルスレッドで作るんじゃねえか？
完全にスレッドが分離してるんなら、別々でも無問題だろ。

873 ：デフォルトの名無しさん：2009/09/24(木) 15:24:47

>>871
すくなくとも *nix は大丈夫なもよう

874 ：871：2009/09/24(木) 15:46:39

>>872-871
レスありがとう

Winsock中級者向けの議論からも次の様な一文を発見

一方のスレッドが send() を呼び出し、別のスレッドが同一のソケットに対して recv() を呼び出すのは安全である、という伝説があります。
しかし私はこれを確認したことはありません。より堅固な情報やデモンストレーション用のコード、さらなる伝説などがあれば、教えていただけると幸いです。

まあとりあえず大丈夫だろうってことですね

875 ：デフォルトの名無しさん：2009/09/24(木) 15:50:58

>>872-873
安価ミス

876 ：デフォルトの名無しさん：2009/09/24(木) 22:21:00

>>871
Solarisは不定期にハングしてたよ
今はどうだかしらんけど・・・

877 ：デフォルトの名無しさん：2009/09/25(金) 12:10:34

送信したらすぐcloseするもの作ってて
close後にレスポンス着てるみたいなんだがshutdownしないとだめ？

878 ：デフォルトの名無しさん：2009/09/25(金) 12:17:15

こっち側で何やっても、レスポンス来るのは抑止できない。

879 ：デフォルトの名無しさん：2009/09/25(金) 12:19:31

>>877
送信スレッドと受信スレッドが別とかって話か？
必要なレスポンスなら何とかしてやるのが筋だろ？
送信側: SHUT_WR 送信で終了
受信側: 読込みバイト数0になるまでレスポンス読んで close
とか………
つか、プロトコル設計見直した方がええんちゃうか？

880 ：デフォルトの名無しさん：2009/09/25(金) 13:55:05

Winsock2を使ってプロミスキャスなパケットモニタを作る場合
送信パケットもモニタできるようにするのは不可能ですか？

WinPcapドライバを使えば送信パケットもモニタできるのだけど・・

881 ：デフォルトの名無しさん：2009/09/25(金) 21:03:37

>>880
できんことは無いけど、それを作り上げていくと
WinPcapドライバが出来てしまうわけで
意味無いよな

882 ：デフォルトの名無しさん：2009/09/26(土) 20:27:52

recvってなんて読むの？

883 ：デフォルトの名無しさん：2009/09/26(土) 20:46:56

>>882
あーるいーしーぶい

884 ：デフォルトの名無しさん：2009/09/27(日) 01:52:41

れくぶ

885 ：デフォルトの名無しさん：2009/09/27(日) 16:29:19

>>881
レスありがとうございます。
いろいろ調べてみた結果、
環境によって送信パケットをモニタできないことがあるみたいです。
別の環境だと普通に送信パケットもモニタできることを確認したので
問題を切り分けてる最中です。
詳しいことがわかりましたら報告させていただきます。

886 ：デフォルトの名無しさん：2009/09/27(日) 21:56:18

WinPcapってずーっと前はpppは拾え無かったよな。今拾えるか知らない。

887 ：デフォルトの名無しさん：2009/09/28(月) 11:40:55

uIPってUDPの単純送信関数無いのか・・・
その上何で今頃気づくんだろう俺orz

888 ：デフォルトの名無しさん：2009/09/28(月) 17:24:01

>>882
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
ｳﾘ達は無理矢理連れて来られて強制労働させられているﾆﾀﾞ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。

889 ：デフォルトの名無しさん：2009/09/29(火) 04:19:15

それを省略するとアルファベット4文字になるのか。パネェ。

890 ：デフォルトの名無しさん：2009/09/29(火) 22:54:09

ﾜﾛﾀ

891 ：デフォルトの名無しさん：2009/09/29(火) 23:21:28

recv深いな・・・

892 ：デフォルトの名無しさん：2009/09/30(水) 01:02:38

次スレのテンプレ入りかもしれな

893 ：デフォルトの名無しさん：2009/10/01(木) 17:46:23

まあ日教組はゴミだけどな。

894 ：デフォルトの名無しさん：2009/10/01(木) 18:13:22

ウヨは巣に帰れよ

895 ：デフォルトの名無しさん：2009/10/01(木) 18:20:38

旧社会党系のうちの社長が俺が産経取ってるのを気にしているようだ・・・ってのはともかくとして。

uIPのUDPサポートが半端だからあれやこれや5種類くらいのスタックを参考にして自前で作ってるわ。
純組込系のスタックは金になるから公開しないのかなぁ。

896 ：デフォルトの名無しさん：2009/10/02(金) 05:38:11

飯の種田氏な。
金払いたくない乞食はリナックスやバークレー辺りから適当にパクってくればいい訳で。その程度で困らないだろうし。

897 ：デフォルトの名無しさん：2009/10/02(金) 11:55:16

でも、それもパクって来た奴だろ。

898 ：デフォルトの名無しさん：2009/10/02(金) 14:59:55

>>895
> 純組込系のスタックは金になるから公開しないのかなぁ。
BSD のスタック移植することが多いかな
CPU の規模によっては、大昔 MIT が IBM PC に実装やつをモディファイ
して使ってる

899 ：デフォルトの名無しさん：2009/10/06(火) 22:23:22

etherealの相談ってここでしてもいい？

900 ：デフォルトの名無しさん：2009/10/06(火) 22:43:08

ええんちゃう？

901 ：デフォルトの名無しさん：2009/10/06(火) 22:57:06

ソースの書き換えとかフィルタの作り方とかなら

902 ：デフォルトの名無しさん：2009/10/06(火) 23:48:30

フィルタのかけ方を聞きたかったんだけど駄目っぽいな
やめておくわ

903 ：デフォルトの名無しさん：2009/10/07(水) 00:25:58

じだいはwiresharkだ

904 ：デフォルトの名無しさん：2009/10/07(水) 11:17:02

wiresharkの相談ってここでしてもいい？

905 ：デフォルトの名無しさん：2009/10/07(水) 11:24:05

パケットキャプチャーとかすげーと思ってたけど
マイコンプログラミングと電子回路始めたら全然すごくないことが
わかった。

906 ：デフォルトの名無しさん：2009/10/07(水) 14:20:19

同意
ケーブルを流れてる定常波から信号を取り出してるのはすごいと思うけどね
promisc自体はたいしたことやってない
ただのbitパターンマッチの繰り返し

907 ：デフォルトの名無しさん：2009/10/07(水) 14:39:35

>>12
selectはヘヴィーロードサーバで、
bitmask処理がオーバーヘッドになる。
>>6辺りからそれを報告した論文を辿れる。

908 ：デフォルトの名無しさん：2009/10/07(水) 20:57:33

wiresharkよりもethreal

909 ：デフォルトの名無しさん：2009/10/07(水) 22:02:58

etherealって開発再開されたの?
wiresharkにほぼそっくり開発チーム移ったよね。

910 ：デフォルトの名無しさん：2009/10/07(水) 23:28:22

そもそもpromiscuousモードは普段やってる処理を省略してるだけ。。

911 ：デフォルトの名無しさん：2009/10/08(木) 04:38:27

>>906
> ケーブルを流れてる定常波から信号を取り出してる
何が言いたいのか意味不明

912 ：デフォルトの名無しさん：2009/10/08(木) 08:50:17

理解力よりスルー力が必要とされてる。

913 ：デフォルトの名無しさん：2009/10/08(木) 09:01:17

>>909
ただの知ったか君だろ

914 ：デフォルトの名無しさん：2009/10/08(木) 18:03:49

tcpdumpこそ(ry

915 ：デフォルトの名無しさん：2009/10/08(木) 22:23:53

敢えてEtherealって言って、昔からやってるっぽく振る舞う技。

916 ：デフォルトの名無しさん：2009/10/09(金) 00:13:15

質問です。
TCP/IPで通信するWindowsプログラムでWinSockの
WSAEventSelect(sock,WM_USER,FD_CLOSE);を使用しています。

このプログラムの接続が確立している状態で物理的にLANを抜くと、
OSがWindows XP・Windows Server 2003の場合WM_USERメッセージが発生し
LPALAMにはWSAのエラーコードが格納されていました。

しかし、同様のことをWindows Vista・Windows Server 2008で行った場合
WM_USERメッセージが発生しなくなりました。
なにか要因わかりますでしょうか？

917 ：デフォルトの名無しさん：2009/10/09(金) 00:17:47

win98の途中から、ケーブルが抜けたらTCP切っちゃうようになって
（ダイアルアップだかの兼ね合いだったと思う）
NT系もwin2000からそうなった気がするが
もしかしてVista/2008からまた昔のに戻ったのかな

あとWM_USERつかうのはやめれ
WM_APPつかえ

918 ：デフォルトの名無しさん：2009/10/09(金) 10:21:32

>>916
ケーブルが抜けただけでは切断しない場合もある。
イベントがでなかったのか接続が切断されていないのかを確認するべし。

919 ：デフォルトの名無しさん：2009/10/09(金) 10:24:04

そもそもTCP/IPは経路上に障害が発生しても即切断にしない設計思想。

920 ：デフォルトの名無しさん：2009/10/09(金) 10:44:09

すばやいレスありがとうございます

XP・2003ではnetstatで接続が消えイベントが発生したのですがVistaでは接続が残ったままとなっています。
Vista以降ウィンドウメッセージのセキュリティが強化されたのが要因かと思っていたんですがnetstafをみると接続を残すのが本来の姿で元に戻した？

現状OSの設定でどうにかならないかとリサーチ中です

921 ：デフォルトの名無しさん：2009/10/09(金) 10:57:07

無線LANでアンテナをロストしただけで切断は困る。
だから元々の設計思想である>>919に統一方向だろう。

そもそも余計な事するなよ、MSと思っていた人が多かった。> INETの人たち
通知するのはいいけど、切断はやりすぎだろと。バカかと。

922 ：デフォルトの名無しさん：2009/10/09(金) 10:57:39

例えケーブルが抜けたことがわかったとしても
その先のルータを越えたところのケーブルが抜けたか
どうかなんてわからないんだから、そのPCのケーブルが
抜けたかどうかなんてわかっても意味がないんだよな

923 ：デフォルトの名無しさん：2009/10/09(金) 11:18:00

だなぁ。
ケーブル抜けても、WIFi繋がってればそっちで通信続ければいいわけだし。

924 ：デフォルトの名無しさん：2009/10/09(金) 11:31:30

そういう話？

925 ：デフォルトの名無しさん：2009/10/09(金) 11:32:57

うん。

926 ：デフォルトの名無しさん：2009/10/09(金) 11:37:42

まあケースの一つだろうね。

いずれにせよ、ケーブルが抜けた、アンテナロストした、
どうやら経路がなくなっているようだ(ICMPなど)、
そういうのを対処するのは基本はOSとデスクトップの仕事で、
アプリが対処すべき場合は希少。
接続切るなんて言語道断。

927 ：デフォルトの名無しさん：2009/10/09(金) 12:27:15

自ホストに直結しているNICやケーブルの物理障害を検出する機構があっても
おかしくは無いが、ソケットレイヤーでやるのは間違い。

928 ：デフォルトの名無しさん：2009/10/09(金) 12:30:11

>>924
自分の階層以外のことに口出しすんな
ってことですかな？

929 ：デフォルトの名無しさん：2009/10/09(金) 12:38:57

メディアの監視はインターフェースレイヤー(ipconfig)でやっている。
必要ならこの階層を使えばいい。
この階層にアクセスするAPIの存在は知らないが。

930 ：デフォルトの名無しさん：2009/10/09(金) 12:48:54

>>928
そんなかんじ

931 ：デフォルトの名無しさん：2009/10/09(金) 16:34:18

プログラミングの仕方の質問なんだけど、
擬似コードを以下に。
// フレームワーク側で、recvイベントが発生した際に呼ばれる関数。
// 受信したデータがbufにバッファリングされてる
void F(buffer &buf){
if(buf.size()==0) return;
// TLV形式で、Typeを取ってくる
switch(buf[0]){
　case MAP_DATA:
　　if(buf.size()<5) return;
　　size_t len = *(size_t*)(&buf[1]);
　　// TLを読み込んだ時点で、読み込んだサイズ分、bufからpopする
　　buf.pop(5);
　　// (＊ここで質問)データを処理する
　　// len分データが届いていなかったら、届いてる分だけ処理してreturnする
}
こういうコードの場合、len分データが届いてなかったらreturnして、またFが呼ばれるのを待つんだけど、
次にFが呼ばれた場合、TLの解析は飛ばして、(＊ここで質問)から処理を再開させたい
んだけど、coroutineとかステートパターンみたいなことを駆使しなきゃダメなの？
それとももっと別の"データを処理するためのコーディング方法/パラダイム"みたいなものがあるの？

932 ：デフォルトの名無しさん：2009/10/09(金) 16:56:05

>>931
動けばいいの。動けば。

933 ：デフォルトの名無しさん：2009/10/09(金) 17:28:24

yaccみたいなパーサジェネレータを作るというのはどうだろう
自前でステート管理のコードを書くかわりに自動生成したコードに管理してもらう
あとは構文とアクションを書くだけ
ただしパーサジェネレータを作るのが面倒いかもしれない

934 ：デフォルトの名無しさん：2009/10/09(金) 17:29:09

>>931
俺はStateパターンというか、状態変数持たせてる。

935 ：デフォルトの名無しさん：2009/10/09(金) 20:04:33

recvの第3引数に受信バッファにあるデータサイズより小さいものを指定した場合
recvで変数に入りきらずあまった分のデータって２度目のrecvで受け取れないの？？

936 ：デフォルトの名無しさん：2009/10/09(金) 20:09:00

TCPなら受け取れる
UDPなら受け取れない

937 ：デフォルトの名無しさん：2009/10/09(金) 20:10:51

ありがとう

938 ：デフォルトの名無しさん：2009/10/09(金) 22:41:28

>>931
自分も>>934と同様に、状態変数で管理してたよ。
・Type待ち
　--> 初期状態
・Length待ち
　--> 1byte固定なら1個、2byte固定なら2個、可変長ならN個の状態
・Value処理中
　--> 受信カウンタを併用(初期値は0, Lengthになれば終了)
実装はインスタンス生成時に受信バッファを渡し、後はgetで取得するイテレータになる。

>>933
(Valueが更にTLVとして定義される)階層的なTLV構造で、それが再帰的である、
または複雑な構造(構文)を持つなら、yaccを使うのは良いアイデアかもしれない。
その場合、前記のイテレータをスキャナ(字句解析)として位置付け、
Typeをトークン(字句)として返すよう実装することになる。

yacc以外だと、precssというコードジェネレータを使うのが良いかもしれない。

939 ：デフォルトの名無しさん：2009/10/09(金) 23:27:21

俺はこないだ「パケット長を知るには最低何バイト読む
必要があるか」というのと、その「読んだバイト列から
パケット長を得る callback」をパラメータにした受信
部を作った。

内部的には皆が言っている「状態」を持っていて、使う
側からのインタフェイスは recv や recvfrom に管理情
報の引数が一つ増える感じ。

940 ：デフォルトの名無しさん：2009/10/09(金) 23:56:07

fdopenするのがお手軽。Winはできたっけ?

941 ：デフォルトの名無しさん：2009/10/10(土) 01:55:16

winsockで通信のコードを書いているのですが、
accept関数で10014のエラーが出てしまいます。
エラー番号の意味は、
呼び出しでポインタ引数を使用するときに、無効なポインタアドレスを検出しました。
らしいのですが、acceptの引数については今まで普通に動いてきたソースのコピペなので
正直なにが悪いのかよく分かりません。どなたか、原因を教えていただけないでしょうか？

http://www.dotup.org/uploda/www.dotup.org241369.cpp.html

942 ：デフォルトの名無しさん：2009/10/10(土) 02:02:14

今まで動いてたけど実はたまたまうまく動いてただけでした＾＾
ってこともまれにある。
ぱっとみ、acceptの代参引数をsizeof( struct sockaddr_in )で初期化してねーだろ

943 ：デフォルトの名無しさん：2009/10/10(土) 02:04:20

自己解決しました。
len = sizeof(client);
をコピペミスしてました。

944 ：デフォルトの名無しさん：2009/10/10(土) 02:07:42

>>942
ありがとうございます。
まさにその部分が原因でした。
コピペ元も初期化してなかったのですが、そっちでは何故かうまく動いてましたｗ
これで1時間くらい悩んでたのですが、書き込んだ直後に解決しました。
スレ汚しすみません。

945 ：938：2009/10/10(土) 02:10:51

レスサンクスコ。
yaccとか難しすぎて俺には無理です。
みんな状態持たせて大変なことやってるんすね
>>938の
>実装はインスタンス生成時に受信バッファを渡し、後はgetで取得するイテレータになる。
「イテレータになる」ってあたりがどういうコードになるのかイメージできません
buffer::iterator iter;
while(true){
　iter = buf.begin(); //TLVの解析はbufferクラスの中に閉じ込める
　if(iter==buf.end()) break;
　// 処理。bufクラスのクライアントはiterから取得するだけ。
}
こんな感じ？

946 ：931：2009/10/10(土) 02:12:20

ごめん。↑は931です

947 ：938：2009/10/10(土) 05:31:28

>>945
>yaccとか難しすぎて俺には無理です。

yaccについては、>>938で書いたのは単なる思いつきだから、スルーでオケー。
ただ、preccsは面白いと思う。一読を薦めるヨ。自分も実際には触った事ないけどネ。

>こんな感じ？
だいたい、そんな感じ(ｗ
ただ、C++のテンプレートは使用せず、一般的なTLVReaderクラスを定義していた。
イテレータという言葉は(>>938のカキコ内では)デザインパターン用語のつもりで書いた。
疑似コードで書くと、こんな感じ。(実際にはC言語で(GTKみたいな)疑似クラスで実装していた)

unsigned char *recv_buf;
TLVReader reader;

reader = TLVReader.new(recv_buf);
while (tlv = reader.get()) {
　switch (tlv.type) {
　case TYPE_XXX_PDU:
　　:　// Type別の処理
　}
}

階層的なTLV構造の場合には、Type別処理の中で、更に別のTLVReaderインスタンスを生成する。

　　xxx_reader = TLVReader.new(tlv.value)
　　while (xxx_tlv = xxx_reader.get()) {
　　　switch (xxx_tlv.type) {
　　　　:　// Sub Typeの処理
　　　}
　　}

948 ：デフォルトの名無しさん：2009/10/10(土) 06:05:50

caseなんか使わずに
メンバ関数へのポインタをメンバに持って
状態が遷移したら、returnする前に次の処理をするメンバ関数を設定するんだ。

いや、可読性を無視するなら、ね。

949 ：デフォルトの名無しさん：2009/10/10(土) 08:36:40

>>940
I/Oイベントドリブンが前提って書いてあるだろ。

950 ：938：2009/10/10(土) 09:59:42

>>947の疑似コードだけど、既にメッセージ全体が受信バッファに読み込まれていること、
あるいは、メッセージが未完成の場合にはget操作内でプロセス(or スレッド)がブロックされる、
言い換えると同期I/Oを前提にしている、という前提がある。
だから、そもそもの質問>>931(未完成時の再開方法)に対するレスとしては不適切だった。

質問の意図に沿って「非同期I/Oを前提(だよね？)」とした場合、最も外側のTLV構造の処理は、
ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。

(続く)

951 ：938：2009/10/10(土) 10:01:02

(>>950の続き)

RecvAcceptorState state = STATE_WAIT_TYPE;　// 初期状態はType待ち

void recv_acceptor()　// recvイベント発生に呼ばれるコールバック関数
{
　while (buf.size() > 0) {
　　byte = buf.pop(1)
　　switch (state) {
　　case STATE_WAIT_TYPE:　// Type待ち状態
　　　tlv.type = byte;　// Type値が決定
　　　state = STATE_WAIT_LEGTH;　// 次の状態(Length待ち)へ遷移
　　　break;
　　case STATE_WAIT_LENGTH:　// Length待ち状態
　　　tlv.length = byte;　// Length値が決定(Lengthフィールドが1byte固定である事を仮定)
　　　value_counter = tlv.length;　// 受信カウンタをLength値で初期化
　　　state = STATE_PROCESS_VALUE;　// 次の状態(Value処理中)へ遷移
　　　break;
　　case STATE_PROCESS_VALUE:　// Value処理中状態
　　　:
　　　if (メッセージ組立て完了) {
　　　　:　// 受信メッセージ処理のアクションを起動する
　　　　:　// もし階層的なTLV構造であれば、>>947のメッセージ解析処理を呼ぶ
　　　　state = STATE_WAIT_TYPE; // 初期状態へ遷移(必要であれば他の再初期化処理も)
　　　}
　　　:
　　　break;
　　}
　}
}

(更に続く)

952 ：938：2009/10/10(土) 10:01:59

(>>951の続き、これで終わり)

>>931の場合、Lengthとして4byte固定を想定しているみたいだから、
上記の疑似コードに対して、Length待ち状態をSTATE_WAIT_LENGTH1..._LENGTH4に分割するか、
あるいはLength受信カウンタを追加する、といった改造を加える必要があるから、注意してね。
他にも、pop値は1byte固定になってるけど、Value処理中状態ではNbyteに高速化すべきだろうし。

953 ：デフォルトの名無しさん：2009/10/10(土) 12:50:43

>>933
yacc 使えばいいんじゃね？
作らなきゃいけないのは、レキシカルアナライザ部分だ。

954 ：デフォルトの名無しさん：2009/10/10(土) 13:14:50

yacc使ってイベント駆動のコード書くの?

955 ：デフォルトの名無しさん：2009/10/10(土) 14:25:34

TLVのデコーダくらいさくっと書けよ。
一度書いたらいろんなプロジェクトで使いまわしできるもんだし。

956 ：デフォルトの名無しさん：2009/10/10(土) 14:29:25

TLVデコーダを書く事に関する質問ではない。

957 ：デフォルトの名無しさん：2009/10/10(土) 16:27:51

>>955じゃないが、元のお題は、
イベント駆動TLVデコーダの話なんじゃないの？

958 ：938：2009/10/10(土) 23:16:02

>>953-957
# スレの流れが錯綜しそうなので、強引にマトメてみる。

最も外側のTLV構造のデコード処理は(>>950-952に書いた)イベント駆動方式(PUSH型)で実現できる。
この部分は比較的に単純なステートマシンだから、わざわざyaccみたいなコードジェネレータを
持ち出す必要性は(個人的には)感じられない(>>957)。

検討課題になるのは、メッセージを組立てた後に、階層的なTLV構造の内側をデコードする
(>>938の)プロセス駆動(PULL型)処理だと思う。
TLV方式は拡張性があるから、必要に応じていくらでも要素を追加できる。
しかも、それに対応するコードは(>>938で書いたような)単純なイテレータで実現できるから、
コピペでコーディングできる。>>955の言葉を借りれば、プロジェクト間で使いまわしができる。
とはいっても単調なコーディング作業の連続だから、(>>948の言う)関数ポインタを活用したり、
あるいはテーブル駆動なコーディング様式を検討したくなるのは、自然な発想だと思う。
そして、それを追求するとTLVデコード処理に特化した俺様言語(DSL)が欲しくなるのも自然な成り行き。

で、DSL(Domain Specific Language)を定義して、その言語処理系(コードジェネレータ)を
開発してみては？という提案が、>>933になる。それに対して、新たにメタ言語を定義して
処理系を開発するのは面倒だから、既に存在しているyaccで(メタ言語を)代用できるんじゃね？
ってのが、>>953の提案。ここでのTLVデコード処理はプロセス駆動方式(PULL型)だから
yaccとの相性は良いかもしれない(>>954)。容易に実現可能である、とまで断定はできないけどね。

(続く)

959 ：938：2009/10/10(土) 23:20:31

(>>958の続き)

最後に、>>956の意図をエスパーしてみたら、通信プロトコル(の状態遷移)そのものをDSLあるいは
yaccで記述できないのか？に読めた。もしそうなら、UNIX板の「yacc & lex」スレ内にある
レス#112-120で議論されていたから、まずそちらを参照してみて。

# 最後に訂正。>>958内にあるアンカ>>938は誤り。>>947が正しい。

960 ：デフォルトの名無しさん：2009/10/11(日) 00:45:27

>>959
イベント駆動だから、yaccで直接書こうとすると、
yyparseをコルーチン化する必要があるぞ。

しかも不完全パケットを受けた状態を
それぞれ非終端記号にする必要がある。
ある程度はまとめられるとしてもね。

>>931のF()は一旦意味のある単位にまとめるのに集中して、
その結果をparseする別のコルーチンに渡すやり方なら簡単だけど。

961 ：デフォルトの名無しさん：2009/10/11(日) 08:29:23

pull型/push型の違いはI/Oライブラリで吸収できる程度の違いなので本質的じゃないですね。

962 ：デフォルトの名無しさん：2009/10/11(日) 10:12:13

なんか >>938 が色々語りたいようだが、内容無くね？うざくね？
解釈勝手すぎくね？全部主観じゃね？うざくね？

963 ：931：2009/10/11(日) 10:20:40

なんか話が高度過ぎてついてけないっす。
push/pullの概念がわかりません
>>960
コルーチンの方が楽っすかね？

とりあえず、>>951みたいな形で
stateとcounterを持たせる方法で書き始めました

>>962
何もしなくて、批判文句垂れる奴がうざいとおもますぅ＞＜

964 ：デフォルトの名無しさん：2009/10/11(日) 11:44:08

>>961
使うフレームワークが固定でそういうわけにもいかないんでしょう

965 ：938：2009/10/11(日) 11:45:06

>>960
yaccとイベント駆動の組み合わせで生まれる問題(push/pull不整合)については、
>>961が1行レスでマトメてくれたので、これ以上はツッこまない。ただ、2点だけ補足。

・イベント駆動問題の解決方法はコルーチンだけではない。UNIX板で紹介したWebアプリの場合、
　(コルーチンを使わずに)別の方法を使ってI/Oライブラリ(yylex()関数)内で吸収させている。

・イベント駆動問題はI/Oライブラリで吸収できる程度の問題だけど、他にも(ライブラリでは
　吸収できない)本質的な問題(制約)が存在する。具体的な内容は省略。

>>963
push/pullやコルーチンなどの話題は、yaccとイベント駆動を組み合わせた場合に限定できるから、
元の質問(>>931)に関しては無視して進めればいいと思うよ。(これも個人的な主観かもしれんが)

966 ：デフォルトの名無しさん：2009/10/11(日) 11:50:38

>>964
フレームワーク(他にもデザインパターンなど)という言葉の幻想(固定観念)に囚われることなかれ

967 ：デフォルトの名無しさん：2009/10/11(日) 12:09:34

>>931
> // フレームワーク側で、recvイベントが発生した際に呼ばれる関数。

このフレームワークを変更可能であると想定していいのかね。

968 ：931：2009/10/11(日) 12:34:35

>>967
一応このフレームワークを使おうって流れ(チームで)なんで変更できなさそうです。
フレームワーク側は、
bonblockingソケットを使っていて、EAGAINを帰すまで読み込んだ後、コールバック呼ぶっぽいです

969 ：デフォルトの名無しさん：2009/10/11(日) 19:50:57

bonblockingソケットって初めて聞いたけど、何だそれは？

970 ：デフォルトの名無しさん：2009/10/11(日) 19:52:00

nとbは隣にある。

971 ：デフォルトの名無しさん：2009/10/11(日) 19:54:13

baruhodo!

972 ：デフォルトの名無しさん：2009/10/11(日) 21:53:20

ボンブロッキングってボンをブロックするみたいでかっこいいな

973 ：デフォルトの名無しさん：2009/10/11(日) 22:58:40

なんだよボンて

974 ：デフォルトの名無しさん：2009/10/11(日) 23:04:43

おはようボンジュールダンスの省略じゃなくて？

975 ：デフォルトの名無しさん：2009/10/12(月) 11:51:39

>>972
ジュールもブロックされそうだな

976 ：デフォルトの名無しさん：2009/10/12(月) 12:01:45

ポンだからジュースだろjk

977 ：デフォルトの名無しさん：2009/10/12(月) 12:23:45

ああ、あの蛇口から出るやつか

978 ：デフォルトの名無しさん：2009/10/12(月) 14:14:55

ビールの専用線とか弾いてるのか？

そろそろ産め。

979 ：デフォルトの名無しさん：2009/10/12(月) 15:20:59

マジレスすると、bonと言えばfriioの事だろ。

980 ：デフォルトの名無しさん：2009/10/12(月) 17:50:53

素朴な疑問です。
ゲームつくるときに、たとえば１２３４５番のポートでお互いUDPで
送受信するとします。
きっとそれはうまくいくんでしょうけど、そもそもだれか別アプリが
わざとこの１２３４５にゴミパケット投げたりしたらどうなるんでしょう。
ゲーム側でいろいろチェックしとかないといけないってことで
いいんでしょうか。

981 ：デフォルトの名無しさん：2009/10/12(月) 18:09:00

>>980
基本的にはそのとおり。

982 ：デフォルトの名無しさん：2009/10/12(月) 18:10:53

>>980
そういうこと
Webプログラミングと似たような感じで、基本は送られて来たデータを信用しない

983 ：デフォルトの名無しさん：2009/10/12(月) 18:36:29

>>981
>>982

どもです。
遅いのを気にしないならTCPにしとけばよいんでしょうか。
仮に１0人でできるゲームだとして、他の全部のマシンとコネクション
はるってのは、なにも送受信してなければメモリもCPUも大した負荷
じゃないんでしょうか。
でも座標いっぱい送りあうなら、あんまりTCP向いてないんですよね？
多人数なアクション作るんだったら、基本TCPはホストになった
マシンとだけはっておいて、あとはUDP１こあけておき、
座標とかどうでもいいものはUDPで、ホスト経由せず全員になげて、
重要なものはTCPでホスト経由でほかのクライアントに通知、とか
でしょうか。

984 ：デフォルトの名無しさん：2009/10/12(月) 18:41:56

TCPでも、どのみちチェックはしなきゃならないよ
悪意のあるクライアントが不正なデータを送りつけてサーバをダウンさせたり乗っ取ろうとするかもしれないし

985 ：デフォルトの名無しさん：2009/10/12(月) 19:00:03

>>983
数十ならTCPでも余裕。
ただ、クライアント/サーバ構成にした方がいいと思うけど。
クライアントはサーバとだけ通信すればいいんで。

986 ：デフォルトの名無しさん：2009/10/12(月) 20:17:01

>>984
チェックていっても、まあマジックナンバーつけるとかチェックサムとか
値のレンジチェックくらいしか思いつかないがおｋ？
>>985
そういうもんなんですね。
なんか気を使ってサーバーに負担をかけないようにとか考えて
ちょくせつクライアント同士でとかおもったけど、
そこまで気にしなくていいってことでしょうか。

987 ：デフォルトの名無しさん：2009/10/12(月) 21:05:19

>>986
マジックナンバーつけて暗号化して、
複合化してマジックナンバーチェックすれば
中間者攻撃でも無い限り大丈夫と思われ。

988 ：デフォルトの名無しさん：2009/10/12(月) 23:58:12

オンラインゲームで中間者攻撃でなくても不正するために
ダミーデーター送りつけたりするひとはいるね
だからマジックナンバーとかチェックサムとか値のレンジチェックは必要

989 ：デフォルトの名無しさん：2009/10/13(火) 08:46:28

>>980
recvfromすればいい。

990 ：デフォルトの名無しさん：2009/10/13(火) 08:52:29

自前でUDP通信作ると輻輳とかならね？
制御しなかったらの話だけど

再送やソートの有無や優先度をパケット単位で指定出来る疑似TCPを
UDPで実装しようと前から思ってるんだが難しい・・・

そういうフリーのライブラリ無いのかねぇ
DirectPlayはそんな感じだったが、今じゃサポート外だしバグもあるらしいし・・・

991 ：デフォルトの名無しさん：2009/10/13(火) 09:06:00

>>990
それならTCP使えばいいじゃんって思うけど、なぜUDPにこだわる？

992 ：デフォルトの名無しさん：2009/10/13(火) 09:22:17

下手な考え休むに似たりって奴だよな。

>>980
connectすればいいんじゃね?

993 ：デフォルトの名無しさん：2009/10/13(火) 09:43:51

再送が必要ないデータと必要なデータを切り分けて効率化したいんだろう？

994 ：デフォルトの名無しさん：2009/10/13(火) 10:31:46

>>993
そりは再送が必要ないデータと必要なデータとで、UDPとTCPを使い分けるか組み合わせればいいんでそ。
NBT(NetBIOS over TCP/IP)だと、アドレス解決にはUDPが、データ転送にはTCPが使用されているし、
逆に、RTSPみたいなストリーミングでは、データ転送にはUDPが、その制御にはTCPが使用されている。
それを、わざわざUDPだけで苦労して実装する価値があるのかが疑問なんだが。

995 ：デフォルトの名無しさん：2009/10/14(水) 00:36:58

・ブロードキャスト／マルチキャストが必要
・TCPの再送が邪魔になる
これらのケース以外は迷わずTCP使ってるな。

996 ：デフォルトの名無しさん：2009/10/14(水) 02:48:10

TCPとUDPの距離があまりに離れすぎているから、
それらの中間の特性を持つプロトコルを
UDP上に実装したくなるというのは分からないでもない。

たとえば、粒度の小さいトランザクションが大量に発生する
大規模分散アプリケーションでは、転送の信頼性が要求される一方で、
コネクションのオーバヘッド(時間/リソース)が無視できなくなる。

997 ：デフォルトの名無しさん：2009/10/14(水) 03:32:17

ume

998 ：デフォルトの名無しさん：2009/10/14(水) 03:33:15

http://pc12.2ch.net/test/read.cgi/tech/1235800707/

999 ：デフォルトの名無しさん：2009/10/14(水) 03:34:39

ume

1000 ：デフォルトの名無しさん：2009/10/14(水) 03:46:48

ネットワークプログラミング相談室 Port25
http://pc12.2ch.net/test/read.cgi/tech/1255459388/

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。