ネットワークプログラミング相談室 Port27
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/12/25(土) 22:46:56Programming 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辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port26
http://hibari.2ch.net/test/read.cgi/tech/1269343909/
関連スレ
ネットワークプログラミング雑談
http://hibari.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://hibari.2ch.net/test/read.cgi/tech/1086238859/
0002デフォルトの名無しさん
2010/12/25(土) 22:49:19Port26 ttp://hibari.2ch.net/test/read.cgi/tech/1269343909/
Port25 ttp://pc12.2ch.net/test/read.cgi/tech/1255459388/
Port24 ttp://pc12.2ch.net/test/read.cgi/tech/1246895188/
Port23 ttp://pc12.2ch.net/test/read.cgi/tech/1230466044/
Port22 ttp://pc11.2ch.net/test/read.cgi/tech/1222603744/
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html
0003デフォルトの名無しさん
2010/12/25(土) 22:50:34UNIXネットワークプログラミング〈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/
0004デフォルトの名無しさん
2010/12/25(土) 22:51:22http://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/
0005デフォルトの名無しさん
2010/12/25(土) 22:52:09★規格
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
0006デフォルトの名無しさん
2010/12/25(土) 22:53:03C10K ヘヴィーロードサーバ
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/
0007デフォルトの名無しさん
2010/12/25(土) 22:56:59ethereal - 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
0008デフォルトの名無しさん
2010/12/26(日) 21:09:02これどういう意味？
WSAGetLastErrorって連続で呼び出したら、エラーコードの情報が
リセットされることってないよね？
ちなみに0が返ってくるのは、クライアント側のウィンドウを強制的に
終了させた時です。
そのときにWSAGETSELECTERRORでエラーになったので、
WSAGetLastErrorでエラーコード取得してみたら0だったんです。
0009デフォルトの名無しさん
2010/12/27(月) 22:20:54while(1) {
recv();
すこし重たい処理;
}
とするとrecvのデータが欠落(跳んでしまう)してしまうみたいなんですが、どう対処したらいんでしょうか
考えたのは
buff格納キューテーブル
thread1 {
while(1) {
recv();
buffをキューテーブルに格納
｝
｝
thread2{
while(1){
キューテーブルを参照、処理
対象データを取り除く
}
}
という素人案ですが、格納にどれくらい負荷が掛かるかも心配で、
何かいい案はないでしょうか？よろしくお願いします
0010デフォルトの名無しさん
2010/12/27(月) 22:29:010011デフォルトの名無しさん
2010/12/28(火) 12:52:52connect関数を使ったのですが必ずエラーになります。
WSAEWOULDBLOCKのエラーが返ってきます。
これは非同期処理においては当たり前のことなのでしょうか？
もしそうなら、SELECT等やタイムアウト時間を自分で設定するしかないのでしょうか？
これは結局同期処理になってる気がするのですが、CONNECTのときは仕方ないのでしょうか？
0012デフォルトの名無しさん
2010/12/28(火) 13:40:55本来はブロッキングする処理だけどノンブロッキングモードだからブロックせずに制御を返したよ（もちろんまだ完了してないよ）
っていう意味だから、あなたの望む結果じゃないのでしょうか？
それともノンブロッキングモードを誤解しているのでしょうか？
単に WSAAsyncSelect の FD_CONNECT の存在に気づいてないだけでしょうか？
0013デフォルトの名無しさん
2010/12/28(火) 13:49:00yes
0014デフォルトの名無しさん
2010/12/28(火) 13:52:43状況が分からないが
connect関数はコール後すぐに制御を返すが、実際にはまだ接続が完了していない。
その状態であることを知らせるのがWSAEWOULDBLOCKであり、
接続が完了したことを通知するのがFD_CONNECT。
connect関数コール後から接続完了（CONNECT）まで何も処理することがないなら一見するとブロッキングモードと同等になる。
しかし、それらの処理がメインスレッド上で行われている場合、ブロッキングするconnect関数コールは、他のWindowsメッセージの処理すらされなくなる。
0015デフォルトの名無しさん
2010/12/29(水) 03:14:11本当にありがとうございました。
FD_CONNECTを待とうと思ったんですが、
色々面倒だったので、select使うことにしました。
メインスレッドで実行しますが、接続時なんで多少ブロックされてもいいと判断しました。
0016デフォルトの名無しさん
2010/12/29(水) 09:01:44select()の待ち時間を0秒にしてもグッとブロックされたりしますか？
それともselect()を使う限りブロックしてしまうものなのでしょうか？
0017デフォルトの名無しさん
2010/12/31(金) 06:55:35送信側と受信側では同じサイズと間隔で下のように送受信しています
for(i=0;i<j;i++)
send(sock,&buf[l],k);
l=l+197;
Sleep(16);
１回のループに196byteなら問題なく送信できるのですが、197にするとエラー（WSAEFAULT）が
発生します。
これは秒間12KBの送受信になるのですが
同じ１台のパソコンでapacheを起動し画像を送受信すると重い画像でも表示できます
原因が思いつく方がいましたらご教授下さい
0018デフォルトの名無しさん
2010/12/31(金) 07:55:00お前のバグ。
WSAEFAULTは&buf[l]が有効なメモリアドレスをさしていない場合に出力される。
0019デフォルトの名無しさん
2010/12/31(金) 10:31:47002017
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;
}
0021デフォルトの名無しさん
2010/12/31(金) 11:00:02len も読み込んだバイト数分減らしたうえで recv に渡す大きさを len に
0022デフォルトの名無しさん
2010/12/31(金) 13:06:10送信側と受信側では同じサイズと間隔で送受信しています
送受信するサイズは4MBで、送信側は４ＭＢ送信できてますが
受信側は4MB受信しないで最後のrecvが0を返して終了します。
受信側でデータが無くなることは実際ありえるのでしょうか？
ちなみに毎回決まったサイズ受信して終了します。
0023デフォルトの名無しさん
2010/12/31(金) 13:30:44＞送信側は４ＭＢ送信できてますが
ちゃんと戻り値を確認してのこと？
0025デフォルトの名無しさん
2010/12/31(金) 13:43:390026デフォルトの名無しさん
2010/12/31(金) 13:53:32普通どれくらい待つのでしょうか？
recvが最後に0を返しても送信サイズと受信サイズが一致しないとループし続けるように
コーディングしましたが、１分ぐらい延々とrecvが0を返し続けました。
002722
2010/12/31(金) 15:05:44途中のデータが欠損しているようです。
最後に特定の文字列を送信してそれは受信できていました。
002822
2010/12/31(金) 15:38:36最初のデータを送信する前に１秒Sleepすると問題なく送受信できました。
0029デフォルトの名無しさん
2010/12/31(金) 15:53:04なんか根本的に間違っていると思う。
やっているのは「非同期通信」なんだろ？
その場合、情報が常に必ず届くという保証がwinsock自体にない。
だから、届かなくてもいいような仕組みを持った通信経路を設計する。
これには色々ある。今の考え方では、すぐに行き詰まると思われ。
0031デフォルトの名無しさん
2010/12/31(金) 16:15:04同期通信なら、保証されるが、それはバグがない場合だ。
何かがバグってるな。
0032デフォルトの名無しさん
2010/12/31(金) 16:15:06>>1のリンクのサイトや本を見てからにしてください
0033デフォルトの名無しさん
2010/12/31(金) 20:02:480034デフォルトの名無しさん
2010/12/31(金) 20:32:45TCPなのかUDPなのか書け。
＃UDPな悪寒。
0035デフォルトの名無しさん
2011/01/01(土) 09:45:33メッセージ境界が保証されていないTCPで、メッセージ境界が保存されて
いると仮定してプログラミングしてるんだろ。
0036デフォルトの名無しさん
2011/01/01(土) 13:50:32ただSOCKET_ERRORかどうかしか見てなくて、実際に受信バイト数までは確認していないってことか？
0037デフォルトの名無しさん
2011/01/01(土) 14:31:53if (recv(sock, buff, BUFF_SIZE, 0) == -1) {
/* エラー処理 */
}
/* BUFF_SIZE 受信したつもりになりきって buff の処理 */
0039デフォルトの名無しさん
2011/01/01(土) 17:26:17sendの戻り値でどうやって受信バイト数を取得すんだよ。
0040デフォルトの名無しさん
2011/01/01(土) 17:27:39で、
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 が戻ってきてれば終了するのではなく、またループに戻るようにする。
0041デフォルトの名無しさん
2011/01/01(土) 18:25:38sendとrecvの戻り値は確認しています。
戻り値が0より大きい場合にその戻り値をlenとしてmemcpyするように
しています。
WSAEWOULDBLOCKについては知りませんでした。
ご指摘ありがとうございます。
0042デフォルトの名無しさん
2011/01/03(月) 08:57:41データを適当なバイト数送るとします。
受信側がそのうち200バイトしか受信できなかったとします。
受信できるまでrecvループしようとしましたが、その間はそこで処理が
止まってしまうので、ウィンドウが固まってしまいます。
なので、一度だけ受信した後、一旦受信処理ルーチンを抜け、
また再度FD_READメッセージを待ちます。
そこで受信できなかった分を受信し、先ほど受信したデータの後ろにMEMCPYでデータを
くっつけようとします
そのためには先ほど受信したデータのバイト数を記録しておく必要があると思います。
さらに、相手は何バイトデータを送ってくるかわかりません。
この場合、まずデータが何バイト送ってきたのかを記録しとくところまではできますが、
何バイトまで受信すればよいのかわかりません。
単純にrecvがsocket_errorを返し、WSAEWOULDBLOCKを返したときが受信データは全て
受信し終わったと判断してよいでしょうか。
0043デフォルトの名無しさん
2011/01/03(月) 09:08:10それをヘッダと言うことが多い
どういう形の書式にするかとかを決めるのがぷろところろろｒ
0044デフォルトの名無しさん
2011/01/03(月) 09:13:49その分だけ受信するってことですか。
いろんなプロトコルがありますが、データサイズだけわかればなんとかなりそうなので、
自分独自のヘッダでも構わないんですよね？
0045デフォルトの名無しさん
2011/01/03(月) 09:32:440046デフォルトの名無しさん
2011/01/03(月) 09:41:100047デフォルトの名無しさん
2011/01/03(月) 10:19:17ストリーム故、同じ思考にいきつくと思うが （fgets はそうでもないか）
0048デフォルトの名無しさん
2011/01/03(月) 12:02:21データ長があらかじめ判らないときには
データ末尾に終了符号をつけることもある
0049デフォルトの名無しさん
2011/01/03(月) 12:03:400050デフォルトの名無しさん
2011/01/03(月) 12:05:410051デフォルトの名無しさん
2011/01/03(月) 12:26:400052デフォルトの名無しさん
2011/01/03(月) 17:33:340053デフォルトの名無しさん
2011/01/03(月) 22:22:320054デフォルトの名無しさん
2011/01/03(月) 23:24:570055デフォルトの名無しさん
2011/01/04(火) 06:45:51ダサい設計だけど、HTTP1.0のようにデータの最後まで送ったら
ソケットを閉じるという方法もある。
0056デフォルトの名無しさん
2011/01/04(火) 07:41:370057デフォルトの名無しさん
2011/01/04(火) 18:57:17亀レスだが、非同期通信に到達性を保証する事は出来ないと思うのだが。
その点について俺が間違っているの教えてくれ。
まず第一に、非同期通信経路上位でのプロトコルによる同期は除いてくれ。
単純に非同期通信経路で、受信側がいつまでたってもデーターはこなかったとしよう。
その場合いつかはタイムアイトになり情報が所か無かったとしよう。
送信側は送信しているので、それが届いたかどうかは感知できない。
この場合どう考えても、情報の到達性を保証する事は出来ない。
ではないのか？
0058デフォルトの名無しさん
2011/01/04(火) 20:24:46何を勘違いしてるのか分からないけど、あの文脈では同期／非同期
はAPIのモードの話で
同期：ブロッキング
非同期：ノン・ブロッキング
でしょ？
それともブロッキングのsend成功＝到達とでも思ってるとか？
0059デフォルトの名無しさん
2011/01/04(火) 20:39:24それを非同期の代名詞にして話す事自体がっかりだよ。あきれた
0060デフォルトの名無しさん
2011/01/04(火) 20:48:37なるのかな？
昔の非同期モデム使ったPPP回線でも（TCPの意味での）到達性は保証
されているのだが。
0061デフォルトの名無しさん
2011/01/04(火) 20:52:45表現するのはごく普通に行われているよ。
なにせWinSockのAPI名がWSAAsyncSelectとかだし。
0062デフォルトの名無しさん
2011/01/04(火) 20:56:59それMSの表現が馬鹿なだけw
だけど、 TCP 使って非同期な通信系ってのはどうゆう意味か説明してほしいな >59
0063デフォルトの名無しさん
2011/01/04(火) 23:11:56非同期型API
がごっちゃになってる？
0064デフォルトの名無しさん
2011/01/05(水) 00:25:14まあ、あまり大声で言わない方がいいと思うがwww。
それに、がっかりしたのも事実だし。言葉の定義はそれでもいいんじゃい。
0065デフォルトの名無しさん
2011/01/05(水) 00:32:52通信相手との同期を取らない点では一種の非同期通信といえるが、いわゆる非同期通信が
単に通信相手からの返事を待たない(同期を取らない)というニュアンスであるのに対し、
ノンブロッキング通信では主に、通信処理の完了を待つことによって他の処理の進行を妨げな
いことを表わしている。
006662
2011/01/05(水) 00:54:39TCP ってのは、 end-end 閉じてないとだめなプロトコルなのね
で、少なくとも、
syn -> syn/ack -> ack
で、コネクションつくって、 こんなやりとりするでしょ？
[data]/ack <-> [data]/ack
この状態が、成立してる限りにおいては同期処理系なのよ
つか、state-fullなプロトコルってのは、どこかで同期する必要があるのは当たり前
もっと上のところでやるのはあんたらの勝手だけど、どの部分指して言ってるの?
ってのが 62 の主旨
0067デフォルトの名無しさん
2011/01/05(水) 01:37:50TCPの実際の動作がわかってない感じだから、どう言っていいのやら...
0068デフォルトの名無しさん
2011/01/05(水) 09:43:14たとえば、HTTP/1.1は非同期。
レスポンスが返ってくる前に、リクエストを投げることができる。非同期だろ。
発端の>>22の「非同期」はWinsockの非同期系APIを指しているのだろうけど。
0069デフォルトの名無しさん
2011/01/05(水) 14:02:26その説明書いた人良く分かってない感じ。
socket APIのブロッキングモードのsendは送信バッファに空きが
出来れば復帰するのであって、通信処理が完了するかどうかとは
関係ない。
0070デフォルトの名無しさん
2011/01/05(水) 14:06:08非同期通信をして、文字だけのやりとりはできるようになりました。
ですが、ユーザごとに名前をつけれてません。
名前付けたいんですが、名前のデータは文字のバッファに含めて送信すべきでしょうか？
それとも名前は名前だけで送ったあとに、後から文字のバッファを送るほうが都合がいいでしょうか？
今はクライアント→サーバにメッセージを送ったら、
サーバから、サーバに接続しているクライアント全てにそのメッセージを送信し、
リアルタイムチャットを作ろうとしているところです。
0071デフォルトの名無しさん
2011/01/05(水) 14:42:280072デフォルトの名無しさん
2011/01/05(水) 14:54:11じゃ、そこまできちっとしたら、ブロッキングモードの通信も非同期だなwwwww
腹抱えて笑うぜwwwwwwwwwwwwwwwww
0073デフォルトの名無しさん
2011/01/05(水) 15:43:18非同期で笑え
0074デフォルトの名無しさん
2011/01/06(木) 14:04:05addr は INET_ANY で create & bind -- (*)
WSAAsyncSelect FD_READ でパケ待ち
パケ到着なFD_READをきっかけに recv & 内部処理開始
内部処理後の応答を パケ送信したピアへ戻したい...
(*)のソケットに write ではうまくいかず
0075デフォルトの名無しさん
2011/01/06(木) 15:08:25recvfromとsendtoを使え
0076デフォルトの名無しさん
2011/01/06(木) 15:16:45recvfrom の末尾で ピアのアドレス受けとれるし…
0077デフォルトの名無しさん
2011/01/09(日) 06:03:35>>58 >>62 どっちとも俺の解釈と違う(と思う)。
まだデータが到着してないときにrecvした場合、
データが来るまで関数が返ってこないのがブロッキング。(1)
関数が返ってきて「まだない」と言われるのがノンブロッキング。(2)
データが到着したことがわかった後で、カーネルに「俺のバッファにコピーしる」
と要求したら、コピー完了後に返ってくるのが同期。(3)
コピー完了前に帰ってきて、コピー完了が別に通知されるのが非同期。(4)
と思ってる。
unixしか知らないひとがよく非同期と誤解してるのが(2)
MSが言ってる非同期は(4)
でないかな？
0078デフォルトの名無しさん
2011/01/09(日) 06:09:27用語の使い方がずれてんだよ、WindowsとUnixは。
今迄画像処理関連のプログラムばかりやってきて
4月からネットワークプログラムの仕事になりそうなんで
異動前に勉強したいんだが
ネットワークプログラムする以前にネットワークに関する知識(スイッチングハブの知識、ネットワークの構成・設計、セキュリティetc)が無い
何かオススメの本あったら教えて
0080デフォルトの名無しさん
2011/01/09(日) 06:16:21recv, send は「非同期I/O」とは呼ばない。
「非同期I/O」は
aio_read, aio_write のこと。
aio_readなんて誰も使ってないだろうけど、
Windowsで言ってる非同期はまさにaio_xxxなんだぜ
0081デフォルトの名無しさん
2011/01/09(日) 08:27:05わかた
ごちそうさま
0082デフォルトの名無しさん
2011/01/09(日) 09:44:33良レスだが、自分の解釈とも異なっている。(もちろん>>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という
システムコールは(まだ)存在していない(はず....)。
0083デフォルトの名無しさん
2011/01/09(日) 11:11:55お前が正しい
正義はお前にある
0084デフォルトの名無しさん
2011/01/09(日) 13:05:50つ ttp://www.amazon.co.jp/dp/4274066770
0085デフォルトの名無しさん
2011/01/09(日) 13:49:290086デフォルトの名無しさん
2011/01/09(日) 18:03:43だな。
そのノンブロッキングの同期が一番おいしいのに
そこを飛び越えてしまったのがWinsock2
0087デフォルトの名無しさん
2011/01/09(日) 23:02:250088デフォルトの名無しさん
2011/01/11(火) 00:22:220089デフォルトの名無しさん
2011/01/11(火) 06:59:470090デフォルトの名無しさん
2011/01/11(火) 16:53:410091デフォルトの名無しさん
2011/01/11(火) 17:13:520092デフォルトの名無しさん
2011/01/11(火) 17:35:060093デフォルトの名無しさん
2011/01/11(火) 17:51:000095デフォルトの名無しさん
2011/01/15(土) 01:41:47なんかITProの記事では、v4アドレスが2011年2月に
枯れるとか言ってるんだがホント？
0096デフォルトの名無しさん
2011/01/15(土) 04:46:13それまでのペースを維持すれば、当然3月くらいまでに無くなるよ。
0097デフォルトの名無しさん
2011/01/15(土) 04:57:00http://www.geekpage.jp/blog/?id=2010/10/18/1
http://journal.mycom.co.jp/news/2010/11/16/074/index.html
アジア地域だと、本当に再来年あたりから
新規v4は無くなる可能性があるみたいね。
v6Readyはもう必須かもしれない。
0098デフォルトの名無しさん
2011/01/18(火) 14:47:48Accept-Encoding: gzip
Range: bytes=41318-
として、順次差分をダウンロードしたいのですが
gzip圧縮された差分がgzipのヘッダー情報を含んでいるらしく
レスポンスのContent-Lengthと食い違いが生じてしまいます
この場合の定番の書き方はどうなっているのでしょうか？
それとも差分ダウンロードと圧縮は同時に使用しないものなのでしょうか？
0099デフォルトの名無しさん
2011/01/18(火) 14:53:31> レスポンスのContent-Lengthと食い違いが生じてしまいます
ダウンロードした圧縮差分を順次つなげていっても
元のgzipファイルにならないという意味です。念のため
0100デフォルトの名無しさん
2011/01/18(火) 15:05:42馬から落馬しそうですね。
0101デフォルトの名無しさん
2011/01/18(火) 15:12:41■ このスレッドは過去ログ倉庫に格納されています