1 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:46:56 ] 主にソケットに関しての質疑応答スレッドです。 Programming UNIX Socket FAQ (日本語訳) www.kt.rim.or.jp/~ksk/sock-faq/indexj.html Winsock Programmer's FAQ (日本語訳) www.kt.rim.or.jp/~ksk/wskfaq-ja/ 関連リンクは>>2-10 辺り 足りなかったら適当に付け足してね 前スレ ネットワークプログラミング相談室 Port26 hibari.2ch.net/test/read.cgi/tech/1269343909/ 関連スレ ネットワークプログラミング雑談 hibari.2ch.net/test/read.cgi/tech/1235800707/ Java ネットワークプログラミング 【教えて!】 hibari.2ch.net/test/read.cgi/tech/1086238859/
4 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:51:22 ] マスタリングTCP/IP RTP編 www.amazon.co.jp/exec/obidos/ASIN/4274065618/ Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法 www.amazon.co.jp/exec/obidos/ASIN/4894714671/ Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析 www.amazon.co.jp/exec/obidos/ASIN/4894715414/ WinSock2.0プログラミング www.amazon.co.jp/exec/obidos/ASIN/4797306882/ 猫でもわかるネットワークプログラミング www.amazon.co.jp/exec/obidos/ASIN/4797323604/ IPv6ネットワークプログラミング www.amazon.co.jp/exec/obidos/ASIN/4756142362/ Visual Basicではじめるネットワークプログラミング超入門 www.amazon.co.jp/exec/obidos/ASIN/4839917523/
5 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:52:09 ] URL抜粋: ★規格 RFC 日本語版リスト www5d.biglobe.ne.jp/~stssk/rfcjlist.html JPNIC RFC関連リンク集 rfc-jp.nic.ad.jp/link/ RFC Editor www.rfc-editor.org/ HTMLなRFC (セクションを直に示すのに便利) www.freesoft.org/CIE/RFC/ RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳 www.studyinghttp.net/cgi-bin/rfc.cgi?2616 IANA Well known port numbers www.iana.org/assignments/port-numbers
6 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:53:03 ] ★プログラミング C10K ヘヴィーロードサーバ www.kegel.com/c10k.html C10K ヘヴィーロードサーバ(日本語訳) www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem MSDN msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp Raw IP Networking FAQ www.whitefang.com/rin/ Java で packet capture netresearch.ics.uci.edu/kfujii/jpcap/doc/ Randomness Recommendations for Security www.faqs.org/rfcs/rfc1750.html BoostSocket www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket The Code Project - Internet & Network programming www.codeproject.com/internet/ ネットワークプログラミングの基礎知識 (問題ありのサイト?) X68000.q-e-d.net/~68user/net/
7 名前:デフォルトの名無しさん mailto:sage [2010/12/25(土) 22:56:59 ] ★ツール類 ethereal - www.ethereal.com/ Wireshark - www.wireshark.org/ tcpdump - www.tcpdump.org/ Windump - netgroup-serv.polito.it/netgroup/tools.html WinPcap - www.winpcap.org/ pathchar - ftp://ftp.ee.lbl.gov/pathchar/ pchar - www.employees.org/~bmah/Software/pchar/ Packetyzer - www.networkchemistry.com/products/packetyzer/ libevent - www.monkey.org/~provos/libevent/ ★プロトコル TTCP www.sean.de/Solaris/ttcp.html www.kohala.com/start/ttcp.html UDP Hole Punching homepage3.nifty.com/toremoro/p2p/firewall.html ★IP, TCP実装 www.iti.fi/documentation/miniip.html www.sics.se/~adam/uip/ www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/ www.geocities.jp/bruce_teller/security/garakuta.htm
8 名前:デフォルトの名無しさん mailto:sage [2010/12/26(日) 21:09:02 ] WSAGetLastErrorでエラーコード取得したんだけど、0だったんだが、 これどういう意味? WSAGetLastErrorって連続で呼び出したら、エラーコードの情報が リセットされることってないよね? ちなみに0が返ってくるのは、クライアント側のウィンドウを強制的に 終了させた時です。 そのときにWSAGETSELECTERRORでエラーになったので、 WSAGetLastErrorでエラーコード取得してみたら0だったんです。
9 名前:デフォルトの名無しさん mailto:sage [2010/12/27(月) 22:20:54 ] winsock2.hで、ローカルアドレスをプロミスキャスモードでtcp通信を全て監視したいのですが、 while(1) { recv(); すこし重たい処理; } とするとrecvのデータが欠落(跳んでしまう)してしまうみたいなんですが、どう対処したらいんでしょうか 考えたのは buff格納キューテーブル thread1 { while(1) { recv(); buffをキューテーブルに格納 } } thread2{ while(1){ キューテーブルを参照、処理 対象データを取り除く } } という素人案ですが、格納にどれくらい負荷が掛かるかも心配で、 何かいい案はないでしょうか?よろしくお願いします
10 名前:デフォルトの名無しさん mailto:sage [2010/12/27(月) 22:29:01 ] 「すこし重たい処理」を「とても軽い処理」にチューニングする。
11 名前:デフォルトの名無しさん mailto:sage [2010/12/28(火) 12:52:52 ] WSAAsyncSelectを使ってノンブロッキングモードの通信を行っています。 connect関数を使ったのですが必ずエラーになります。 WSAEWOULDBLOCKのエラーが返ってきます。 これは非同期処理においては当たり前のことなのでしょうか? もしそうなら、SELECT等やタイムアウト時間を自分で設定するしかないのでしょうか? これは結局同期処理になってる気がするのですが、CONNECTのときは仕方ないのでしょうか?
12 名前:デフォルトの名無しさん mailto:sage [2010/12/28(火) 13:40:55 ] WSAEWOULDBLOCK は、 本来はブロッキングする処理だけどノンブロッキングモードだからブロックせずに制御を返したよ(もちろんまだ完了してないよ) っていう意味だから、あなたの望む結果じゃないのでしょうか? それともノンブロッキングモードを誤解しているのでしょうか? 単に WSAAsyncSelect の FD_CONNECT の存在に気づいてないだけでしょうか?
13 名前:デフォルトの名無しさん mailto:sage [2010/12/28(火) 13:49:00 ] >>11 これは非同期処理においては当たり前のことなのでしょうか? yes
14 名前:デフォルトの名無しさん mailto:sage [2010/12/28(火) 13:52:43 ] >>11 状況が分からないが connect関数はコール後すぐに制御を返すが、実際にはまだ接続が完了していない。 その状態であることを知らせるのがWSAEWOULDBLOCKであり、 接続が完了したことを通知するのがFD_CONNECT。 connect関数コール後から接続完了(CONNECT)まで何も処理することがないなら一見するとブロッキングモードと同等になる。 しかし、それらの処理がメインスレッド上で行われている場合、ブロッキングするconnect関数コールは、他のWindowsメッセージの処理すらされなくなる。
15 名前:デフォルトの名無しさん mailto:sage [2010/12/29(水) 03:14:11 ] >>12-14 本当にありがとうございました。 FD_CONNECTを待とうと思ったんですが、 色々面倒だったので、select使うことにしました。 メインスレッドで実行しますが、接続時なんで多少ブロックされてもいいと判断しました。
16 名前:デフォルトの名無しさん mailto:sage [2010/12/29(水) 09:01:44 ] >>15 select()の待ち時間を0秒にしてもグッとブロックされたりしますか? それともselect()を使う限りブロックしてしまうものなのでしょうか?
17 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 06:55:35 ] winsockの非同期通信で1台のパソコンで通信のプログラムを作っています 送信側と受信側では同じサイズと間隔で下のように送受信しています for(i=0;i<j;i++) send(sock,&buf[l],k); l=l+197; Sleep(16); 1回のループに196byteなら問題なく送信できるのですが、197にするとエラー(WSAEFAULT)が 発生します。 これは秒間12KBの送受信になるのですが 同じ1台のパソコンでapacheを起動し画像を送受信すると重い画像でも表示できます 原因が思いつく方がいましたらご教授下さい
18 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 07:55:00 ] >>17 お前のバグ。 WSAEFAULTは&buf[l]が有効なメモリアドレスをさしていない場合に出力される。
19 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 10:31:47 ] てすと
20 名前:17 mailto:sage [2010/12/31(金) 10:45:45 ] 解決しました 原因はサーバ側でrecvのbufの使い方が間違ってました recvは必ず指定したサイズを受信するわけではないので 不便だと思い下のような関数を作ってたのですが おそらくはcのアドレスを直接渡したのが原因か またはcのアドレスをサイズ分移動させた後のアドレスと 固定のサイズの4096が一致しないのが原因かと思います 正しい原因は調べてないですが、改善例のように修正したら 問題なく動作するようになりました。 int recv2(SOCKET s,char buf[],int len){ char *c=buf; char wrk[4096]; while(1){ i=recv(s,c,4096,0);駄目な例 i=recv(s,wrk,4096,0);改善例 memcpy(c,wrk,i);改善例 if(i==SOCKET_ERROR){ shutdown(s,2); closesocket(s); return 0; } c=c+i; }
21 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 11:00:02 ] c を読み込んだバイト数分進めてるついでに len も読み込んだバイト数分減らしたうえで recv に渡す大きさを len に
22 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 13:06:10 ] winsockの非同期通信で1台のパソコンで通信のプログラムを作っています 送信側と受信側では同じサイズと間隔で送受信しています 送受信するサイズは4MBで、送信側は4MB送信できてますが 受信側は4MB受信しないで最後のrecvが0を返して終了します。 受信側でデータが無くなることは実際ありえるのでしょうか? ちなみに毎回決まったサイズ受信して終了します。
23 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 13:30:44 ] >>22 >送信側は4MB送信できてますが ちゃんと戻り値を確認してのこと?
24 名前:22 mailto:sage [2010/12/31(金) 13:39:22 ] >>23 sendの戻り値は確認しています。
25 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 13:43:39 ] ちょっと連絡が来ないからといって破局と決定するのはどうかと
26 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 13:53:32 ] >>25 普通どれくらい待つのでしょうか? recvが最後に0を返しても送信サイズと受信サイズが一致しないとループし続けるように コーディングしましたが、1分ぐらい延々とrecvが0を返し続けました。
27 名前:22 mailto:sage [2010/12/31(金) 15:05:44 ] 受信データを少し調べてみたら 途中のデータが欠損しているようです。 最後に特定の文字列を送信してそれは受信できていました。
28 名前:22 mailto:sage [2010/12/31(金) 15:38:36 ] 結局原因は分からなかったのですが、最初のデータが欠損していましたので 最初のデータを送信する前に1秒Sleepすると問題なく送受信できました。
29 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 15:53:04 ] >>22 ,28 なんか根本的に間違っていると思う。 やっているのは「非同期通信」なんだろ? その場合、情報が常に必ず届くという保証がwinsock自体にない。 だから、届かなくてもいいような仕組みを持った通信経路を設計する。 これには色々ある。今の考え方では、すぐに行き詰まると思われ。
30 名前:22 mailto:sage [2010/12/31(金) 16:06:38 ] >>29 申し訳ない 同期通信の間違いでした。 TCP/IP自体データが保障されていると思ってたんだけど 違うのでしょうか?
31 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 16:15:04 ] >>30 同期通信なら、保証されるが、それはバグがない場合だ。 何かがバグってるな。
32 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 16:15:06 ] あなたはここで質問するレベルですらないので >>1 のリンクのサイトや本を見てからにしてください
33 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 20:02:48 ] ??到達性に同期も非同期も関係ないだろ?
34 名前:デフォルトの名無しさん mailto:sage [2010/12/31(金) 20:32:45 ] >>22 TCPなのかUDPなのか書け。 #UDPな悪寒。
35 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 09:45:33 ] 逆。 メッセージ境界が保証されていないTCPで、メッセージ境界が保存されて いると仮定してプログラミングしてるんだろ。
36 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 13:50:32 ] >>24 で戻り値は確認していると言っているからおれはないと思うが。 ただSOCKET_ERRORかどうかしか見てなくて、実際に受信バイト数までは確認していないってことか?
37 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 14:31:53 ] >>36 Unixでも初心者に良くいるよ、こうかくやつは… if (recv(sock, buff, BUFF_SIZE, 0) == -1) { /* エラー処理 */ } /* BUFF_SIZE 受信したつもりになりきって buff の処理 */
38 名前:22 mailto:sage [2011/01/01(土) 17:02:14 ] >>34 TCPです UDPは信頼性がなさそうなので
39 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 17:26:17 ] >>36 sendの戻り値でどうやって受信バイト数を取得すんだよ。
40 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 17:27:39 ] >>38 で、 n=send(sock,buff, BUFF_SIZE, 0); n=recv(sock, buff, BUFF_SIZE, 0); いずれもBUFF_SIZEまで送信受信できているとは限らない。 n がSOCKET_ERRORではない場合、n は実際に送信受信したバイト数になっているが、 その n の値もしっかり反映しているの? それと、SOCKET_ERROR の場合は終了しているようなので関係ないが 送信受信において SOCKET_ERRORが戻ってきた場合のWSAGetLastError() の戻り値も確認する。 WSAEWOULDBLOCK が戻ってきてれば終了するのではなく、またループに戻るようにする。
41 名前:デフォルトの名無しさん mailto:sage [2011/01/01(土) 18:25:38 ] >>40 sendとrecvの戻り値は確認しています。 戻り値が0より大きい場合にその戻り値をlenとしてmemcpyするように しています。 WSAEWOULDBLOCKについては知りませんでした。 ご指摘ありがとうございます。
42 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 08:57:41 ] TCP/IP通信でWSAAsyncSelectを使って非同期通信をしています。 データを適当なバイト数送るとします。 受信側がそのうち200バイトしか受信できなかったとします。 受信できるまでrecvループしようとしましたが、その間はそこで処理が 止まってしまうので、ウィンドウが固まってしまいます。 なので、一度だけ受信した後、一旦受信処理ルーチンを抜け、 また再度FD_READメッセージを待ちます。 そこで受信できなかった分を受信し、先ほど受信したデータの後ろにMEMCPYでデータを くっつけようとします そのためには先ほど受信したデータのバイト数を記録しておく必要があると思います。 さらに、相手は何バイトデータを送ってくるかわかりません。 この場合、まずデータが何バイト送ってきたのかを記録しとくところまではできますが、 何バイトまで受信すればよいのかわかりません。 単純にrecvがsocket_errorを返し、WSAEWOULDBLOCKを返したときが受信データは全て 受信し終わったと判断してよいでしょうか。
43 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 09:08:10 ] 普通は送られてくるデータの先頭あたりにデータ長の情報が含まれる それをヘッダと言うことが多い どういう形の書式にするかとかを決めるのがぷろところろろr
44 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 09:13:49 ] ヘッダを作って、最初にその数バイトだけ読んでデータの大きさを調べて、 その分だけ受信するってことですか。 いろんなプロトコルがありますが、データサイズだけわかればなんとかなりそうなので、 自分独自のヘッダでも構わないんですよね?
45 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 09:32:44 ] 馬鹿の考え休むに似たり
46 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 09:41:10 ] どうにかするわ
47 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 10:19:17 ] 一度、標準入出力で書いてみりゃ良いのに… ストリーム故、同じ思考にいきつくと思うが (fgets はそうでもないか)
48 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 12:02:21 ] >>44 データ長があらかじめ判らないときには データ末尾に終了符号をつけることもある
49 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 12:03:40 ] その場合データ中に終了符号と同じデータを含めることは出来ない
50 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 12:05:41 ] こういうのデザパタで何て言うんだっけ?
51 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 12:26:40 ] 改行区切りパターン(いま考えた)
52 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 17:33:34 ] 皆さんありがとうございます。とにかくやってみます!
53 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 22:22:32 ] まとめてやるんじゃなくて、1バイト毎にやったほうがいい時もある。
54 名前:デフォルトの名無しさん mailto:sage [2011/01/03(月) 23:24:57 ] なにいってんだおまえ
55 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 06:45:51 ] >>48 ダサい設計だけど、HTTP1.0のようにデータの最後まで送ったら ソケットを閉じるという方法もある。
56 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 07:41:37 ] 別にださくないんじゃね、 ftp もそうだけど…
57 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 18:57:17 ] >>33 亀レスだが、非同期通信に到達性を保証する事は出来ないと思うのだが。 その点について俺が間違っているの教えてくれ。 まず第一に、非同期通信経路上位でのプロトコルによる同期は除いてくれ。 単純に非同期通信経路で、受信側がいつまでたってもデーターはこなかったとしよう。 その場合いつかはタイムアイトになり情報が所か無かったとしよう。 送信側は送信しているので、それが届いたかどうかは感知できない。 この場合どう考えても、情報の到達性を保証する事は出来ない。 ではないのか?
58 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 20:24:46 ] >>57 何を勘違いしてるのか分からないけど、あの文脈では同期/非同期 はAPIのモードの話で 同期:ブロッキング 非同期:ノン・ブロッキング でしょ? それともブロッキングのsend成功=到達とでも思ってるとか?
59 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 20:39:24 ] なんだ、ノン・ブロッキングの事を言っているのか、がっかりだな。 それを非同期の代名詞にして話す事自体がっかりだよ。あきれた
60 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 20:48:37 ] じゃあどういう意味の”非同期通信”ならTCPで到達性が保証できなく なるのかな? 昔の非同期モデム使ったPPP回線でも(TCPの意味での)到達性は保証 されているのだが。
61 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 20:52:45 ] それにブロッキング /ノン・ブロッキング を同期/非同期って 表現するのはごく普通に行われているよ。 なにせWinSockのAPI名がWSAAsyncSelectとかだし。
62 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 20:56:59 ] >>61 それMSの表現が馬鹿なだけw だけど、 TCP 使って非同期な通信系ってのはどうゆう意味か説明してほしいな >59
63 名前:デフォルトの名無しさん mailto:sage [2011/01/04(火) 23:11:56 ] 非同期通信 非同期型API がごっちゃになってる?
64 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 00:25:14 ] 言葉の定義の問題だから、おまえの中では非同期でいいんじゃない。 まあ、あまり大声で言わない方がいいと思うがwww。 それに、がっかりしたのも事実だし。言葉の定義はそれでもいいんじゃい。
65 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 00:32:52 ] 参考までに、IT辞書のノンブロッキングの説明部分を張っとく。 通信相手との同期を取らない点では一種の非同期通信といえるが、いわゆる非同期通信が 単に通信相手からの返事を待たない(同期を取らない)というニュアンスであるのに対し、 ノンブロッキング通信では主に、通信処理の完了を待つことによって他の処理の進行を妨げな いことを表わしている。
66 名前:62 mailto:sage [2011/01/05(水) 00:54:39 ] >>63 おれ? TCP ってのは、 end-end 閉じてないとだめなプロトコルなのね で、少なくとも、 syn -> syn/ack -> ack で、コネクションつくって、 こんなやりとりするでしょ? [data]/ack <-> [data]/ack この状態が、成立してる限りにおいては同期処理系なのよ つか、state-fullなプロトコルってのは、どこかで同期する必要があるのは当たり前 もっと上のところでやるのはあんたらの勝手だけど、どの部分指して言ってるの? ってのが 62 の主旨
67 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 01:37:50 ] 上位のAPIの動きで話が進むんだよね。 TCPの実際の動作がわかってない感じだから、どう言っていいのやら...
68 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 09:43:14 ] >>66 たとえば、HTTP/1.1は非同期。 レスポンスが返ってくる前に、リクエストを投げることができる。非同期だろ。 発端の>>22 の「非同期」はWinsockの非同期系APIを指しているのだろうけど。
69 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 14:02:26 ] >>65 その説明書いた人良く分かってない感じ。 socket APIのブロッキングモードのsendは送信バッファに空きが 出来れば復帰するのであって、通信処理が完了するかどうかとは 関係ない。
70 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 14:06:08 ] チャット作ってます。 非同期通信をして、文字だけのやりとりはできるようになりました。 ですが、ユーザごとに名前をつけれてません。 名前付けたいんですが、名前のデータは文字のバッファに含めて送信すべきでしょうか? それとも名前は名前だけで送ったあとに、後から文字のバッファを送るほうが都合がいいでしょうか? 今はクライアント→サーバにメッセージを送ったら、 サーバから、サーバに接続しているクライアント全てにそのメッセージを送信し、 リアルタイムチャットを作ろうとしているところです。
71 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 14:42:28 ] この流れで「非同期通信」の質問は釣りにしか見えない。
72 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 14:54:11 ] >>69 じゃ、そこまできちっとしたら、ブロッキングモードの通信も非同期だなwwwww 腹抱えて笑うぜwwwwwwwwwwwwwwwww
73 名前:デフォルトの名無しさん mailto:sage [2011/01/05(水) 15:43:18 ] >>72 非同期で笑え
74 名前:デフォルトの名無しさん mailto:sage [2011/01/06(木) 14:04:05 ] Winsock2 : UDP : 鯖側 addr は INET_ANY で create & bind -- (*) WSAAsyncSelect FD_READ でパケ待ち パケ到着なFD_READをきっかけに recv & 内部処理開始 内部処理後の応答を パケ送信したピアへ戻したい... (*)のソケットに write ではうまくいかず
75 名前:デフォルトの名無しさん mailto:sage [2011/01/06(木) 15:08:25 ] なぜwrite? recvfromとsendtoを使え
76 名前:デフォルトの名無しさん mailto:sage [2011/01/06(木) 15:16:45 ] あ。 単純ミスorz recvfrom の末尾で ピアのアドレス受けとれるし…
77 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 06:03:35 ] 新スレに今気づいた俺が横からレス >>58 >>62 どっちとも俺の解釈と違う(と思う)。 まだデータが到着してないときにrecvした場合、 データが来るまで関数が返ってこないのがブロッキング。(1) 関数が返ってきて「まだない」と言われるのがノンブロッキング。(2) データが到着したことがわかった後で、カーネルに「俺のバッファにコピーしる」 と要求したら、コピー完了後に返ってくるのが同期。(3) コピー完了前に帰ってきて、コピー完了が別に通知されるのが非同期。(4) と思ってる。 unixしか知らないひとがよく非同期と誤解してるのが(2) MSが言ってる非同期は(4) でないかな?
78 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 06:09:27 ] すまん誤解は言いすぎだ 用語の使い方がずれてんだよ、WindowsとUnixは。
79 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 06:11:24 BE:1862599474-2BP(0)] 適したスレがぱっと見当たらなかったのでここで質問させてください 今迄画像処理関連のプログラムばかりやってきて 4月からネットワークプログラムの仕事になりそうなんで 異動前に勉強したいんだが ネットワークプログラムする以前にネットワークに関する知識(スイッチングハブの知識、ネットワークの構成・設計、セキュリティetc)が無い 何かオススメの本あったら教えて
80 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 06:16:21 ] もう一個補足。Unix(Posix.1)で recv, send は「非同期I/O」とは呼ばない。 「非同期I/O」は aio_read, aio_write のこと。 aio_readなんて誰も使ってないだろうけど、 Windowsで言ってる非同期はまさにaio_xxxなんだぜ
81 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 08:27:05 ] >>80 わかた ごちそうさま
82 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 09:44:33 ] >>77 ,80 良レスだが、自分の解釈とも異なっている。(もちろん>>58 ,62とも違う) >>77 の例であれば、どちらも同期(という総称的な概念を指す用語)の一種であり、 それらの違いは「データ到着」と「コピー完了」というイベント種別の違いでしかない、いうのが自分の解釈。 ブロッキングは同期(という目的)を実現する手段であり、両者を同列に比較/分類する事は無意味であると思う。 まとめると、>>77 の(1)と(2)は同じだが、(3)はブロッキングモードのrecvであり、(4)はノンブロッキングモードの 非同期recvであり、さらに(3')としてノンブロッキングモードの同期recvが加わる。 Unixであれば、read/write/recv/sendは、どれもブロッキングモード/ノンブロッキングモードのどちらでも 操作を実行できる。ただしノンブロッキングモードの場合、データ未着/コピー未完であればアプリ側で定期的に リトライしなければならないという(性能上の)問題があるため、必然的にブロッキングモードを使わざるをえなかった。 この課題を解決する為に考案(追加)されたのが、aio_read/aio_writeと呼ばれる、いわゆるAIO(非同期I/O)という仕掛け。 ちなみにLinuxのAIO実装の場合、ソケットに対するAIOはサポートされていないから、aio_recv/aio_sendという システムコールは(まだ)存在していない(はず....)。
83 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 11:11:55 ] >>82 お前が正しい 正義はお前にある
84 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 13:05:50 ] >79 つ ttp://www.amazon.co.jp/dp/4274066770
85 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 13:49:29 ] つ www.amazon.co.jp/dp/4839909555
86 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 18:03:43 ] >さらに(3')としてノンブロッキングモードの同期recvが加わる。 だな。 そのノンブロッキングの同期が一番おいしいのに そこを飛び越えてしまったのがWinsock2
87 名前:デフォルトの名無しさん mailto:sage [2011/01/09(日) 23:02:25 ] ふつーIO完了ポート
88 名前:デフォルトの名無しさん mailto:sage [2011/01/11(火) 00:22:22 ] 何で非同期IOの方が効率がいいっていわれてんの?
89 名前:デフォルトの名無しさん mailto:sage [2011/01/11(火) 06:59:47 ] 待たなくていいから待ってる間に他のことが出来る
90 名前:デフォルトの名無しさん [2011/01/11(火) 16:53:41 ] インタラクティブなアプレットをなにか作らないといけないのですが、誰か助けてください
91 名前:デフォルトの名無しさん mailto:sage [2011/01/11(火) 17:13:52 ] おせちアプレットでも作ってください。
92 名前:デフォルトの名無しさん mailto:sage [2011/01/11(火) 17:35:06 ] 重箱におせちを詰めるゲームか
93 名前:デフォルトの名無しさん mailto:sage [2011/01/11(火) 17:51:00 ] ボリュームが足りないくらいがちょうどいい
94 名前:デフォルトの名無しさん [2011/01/12(水) 08:46:27 BE:1197386429-2BP(0)] >>84 ,>>85 レスありがとうございます。 スレ違いにも関わらず…助かります。
95 名前:デフォルトの名無しさん mailto:sage [2011/01/15(土) 01:41:47 ] IPv6 そろそろ端末側も本格対応が必要なのかな なんかITProの記事では、v4アドレスが2011年2月に 枯れるとか言ってるんだがホント?
96 名前:デフォルトの名無しさん mailto:sage [2011/01/15(土) 04:46:13 ] 去年10月の時点で残り7ブロックとかそういう話でしょ。 それまでのペースを維持すれば、当然3月くらいまでに無くなるよ。
97 名前:デフォルトの名無しさん mailto:sage [2011/01/15(土) 04:57:00 ] とりあえず拾ってみた。 www.geekpage.jp/blog/?id=2010/10/18/1 journal.mycom.co.jp/news/2010/11/16/074/index.html アジア地域だと、本当に再来年あたりから 新規v4は無くなる可能性があるみたいね。 v6Readyはもう必須かもしれない。
98 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 14:47:48 ] HTTPプロトコルで Accept-Encoding: gzip Range: bytes=41318- として、順次差分をダウンロードしたいのですが gzip圧縮された差分がgzipのヘッダー情報を含んでいるらしく レスポンスのContent-Lengthと食い違いが生じてしまいます この場合の定番の書き方はどうなっているのでしょうか? それとも差分ダウンロードと圧縮は同時に使用しないものなのでしょうか?
99 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 14:53:31 ] > gzip圧縮された差分がgzipのヘッダー情報を含んでいるらしく > レスポンスのContent-Lengthと食い違いが生じてしまいます ダウンロードした圧縮差分を順次つなげていっても 元のgzipファイルにならないという意味です。念のため
100 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 15:05:42 ] HyperText Transfer Protocolプロトコルですか。 馬から落馬しそうですね。
101 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 15:12:41 ] 何を転送しようとして何を期待して実際どうなったのかさっぱりわからん・・・
102 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 15:14:44 ] 単に複数レスポンスをそのままファイルマージしちゃっただけのような 1レスポンス→unzip→マージ じゃないのかなぁ…
103 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 15:45:14 ] リソース本体 - CTE: gzip 処理 - 部分抜き出し(こいつの大きさが CL) - ヘッダ追加 の順を期待してた 流れてきてるのは リソース本体 - 部分抜き出し - CTE: gzip 処理(こいつの大きさが CL) - ヘッダ追加 の順だった プロトコルとして正しいのはどっちかは知らない
104 名前:デフォルトの名無しさん mailto:sage [2011/01/18(火) 16:59:52 ] すいません、説明が悪かったです やりたいことは2chのスレッドのダウンロードです 最初はAccept-Encoding: gzip、Rangeでダウンロードして展開したファイルのサイズを渡していたのですが、 416 Requested Range Not Satisfiableが着てしまってダメでした。 gzipの位置ではないかと推測して、 今度はダウンロードしたgzipのサイズを渡して、差分のダウンロード自体は成功したのですが、 展開すると、一番最初にダウンロードしたブロックしか展開されません。 ファイルの残りの部分は無視されてしまいます。 ここまでやって混乱してきたのでご相談に上がった次第です よろしくお願いいたします