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

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

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辺り
足りなかったら適当に付け足してね

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

過去スレ：
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

図書コーナー:
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/

マスタリング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/

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

★プログラミング
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/

★ツール類
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

リンク切れぐらいは消せよ

文句言うならお前が立てるか前スレで指摘しとけクソ野郎

コピペしか出来ないコーダーは立てるなよ

なら立てる前にちゃんと立てろ役立たず

とりあえず>>1乙

まずはプログラムやる前にtcp/ipの本読もうぜって感じだな。

残り3レスしか無かったし、次スレ誘導くらいはしたかったから
いちいちリンク確認してる暇なかったんだわ
次スレではよろしく

/　　　//　　　/　　　//　　　 ______　　　　　/　　　//　　　/
　/　// 　 /| 　 r'7＼　,.ﾍ‐'"´iヾ､／＼ﾆ''ｰ- ､.,　　 /　　　　/
　　/ 　 ／　|　 |::|ｧ'⌒',ヽ:::ヽrﾍ_,,.!-‐-'､二7-ｧ'´|､__
`'ｰ-‐''"　　 ヽ､_'´　　`|　|:::::|'"　　　　　　　二.,_> ,.へ_
　　　　　　　　 /　 ／/__/／　/ ／　／　 　　 　`ヽ7::/
　か　っ　も　 |　 ／　/／　メ,/_,,. /./　/| 　 i　　　Y　　　//
　ァ　 て　う.　 |'´/ ∠. -‐'ｧ'"´'`iヽ./／ ﾒ､,_ﾊ　 ,　 |〉
　 |　 約　ク　 ヽ! Ｏ .|/。〈ﾊ､　rﾘ　'´ 　 ,ｧ=;､`| ,ﾊ　|､　　/
　 |　 束　ソ　　　>　　o　 ゜,,´￣　　　. 　ﾄ i 〉.ﾚ'i　iヽ|ヽ､.,____
　 | 　し　 ス　　/　　 ハ |　u 　 ,.--- ､ 　`' ゜o Ｏ/､.,___,,..-‐'"´
　 |　 た　 レ　 |　　/ 　ハ, 　 /　　　　〉　"从　 ヽ!　　/
　 |　 じ　 は 　|,.イ,.!-‐'-'､,ﾍ. !､_ 　 _,/　,.ｲﾍ. `　　ヽ.
　ッ　.ゃ　.立 　 |／　　　　 ヽ!7＞ｒｧ''7´|　/　',　 〉`ヽ〉
　! !　な 　て　　 .',　　　　　　`Y_,/､レ'ﾍ/ﾚ'　　ﾚ'
　　　い 　.な　 　 ヽ､_　　　　　!:::::ﾊiヽ.　　　//　　 /
　　　で 　 い　　　.／‐r'､.,_,.イ＼/_」ヽ ', 　　　　　 /　 /
　　　す　 　　　　/　　　 `/:::::::/　/,」:::iﾝ､ /　　　 /
　　　　 　　　　 〈　 ,,..-‐''"´￣￣77ｰ--､_＼.,__　　/
　　　　　　,.:'⌒ヽ ´ 　 　　　　　 | |　 , i |ﾉ　　 `ヾr-､

これら俺のとこからリンク駄目だな。繋がるか？
★プログラミング
MSDN
　http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
　http://www.whitefang.com/rin/
The Code Project - Internet & Network programming
　http://www.codeproject.com/internet/

★ツール類
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/

★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.geocities.jp/bruce_teller/security/garakuta.htm

http://www.sics.se/~adam/uip/
これはだいじょうぶ

>>3の一番上の本だけじゃプログラムでの簡単なファイアウォールの作成はきついですか？

そんな質問してる人には無理

簡単だよ
http://ruffnex.oc.to/kenji/text/fire_a/

>>19
個人の技術力うんぬんでなくその本でファイアウォールを作るだけの知識が
つくか聞いたんだす。
>>20
windows持ってないんです。。

どうやら上記の本だけでは無理っぽいですね。
パケット単位での取扱いはAPIじゃ難しいと某巨大掲示板に書いてありました。
とりあえずサーバをプログラムで作って、その後、勉強しようと思います。

WSAAsyncSelectでイベント型のクライアント作ってるんだが
接続時のタイムアウトはどうやればいいの？
ioctlsocket + selectだとタイムアウトするまでメッセージ処理が止まっちゃうし

ネットワーク以前に、もうちょっとプログラミングスキル高めたほうがいいよ。無茶過ぎる。

http://pc12.2ch.net/test/read.cgi/tech/1263738929/
VB.NET質問スレ(Part33)
http://pc12.2ch.net/test/read.cgi/tech/1267775473/
【初心者歓迎】C/C++室 Ver.72【環境依存OK】
http://pc12.2ch.net/test/read.cgi/tech/1269517734/
C言語なら俺に聞け（入門編）Part 62
http://pc12.2ch.net/test/read.cgi/tech/1269438098/
C/C++の宿題片付けます 135代目
http://pc12.2ch.net/test/read.cgi/tech/1268699491/
スレ立てるまでもない質問はここで 105匹目

Linuxで、/proc/fdの下見るとソケット一覧が見られるけど
ここにちょっかいを出してネットワークを切断したいと思います。
いい方法はありますか？

関係ないけど sudo rm -rf /proc/fd とかやるとどうなるのかな?

>>24
ソケットの場合は/proc/<pid>/fdは単にsocket[<inode番号>]
という文字列を含むシンボリックリンクであり、参照的な機能しか
無いようだ。　

ls -l /proc/21853/fd
total 0
lrwx------ 1 root root 64 Apr 3 15:14 0 -> /dev/pts/16
lrwx------ 1 root root 64 Apr 3 15:14 1 -> /dev/pts/16
lrwx------ 1 root root 64 Apr 3 15:14 2 -> /dev/pts/16
lrwx------ 1 root root 64 Apr 3 15:14 3 -> socket:[27284825]
# file /proc/21853/fd/3
/proc/21853/fd/3: broken symbolic link to `socket:[27284825]'
# whoami
root
# rm -f /proc/21853/fd/3
rm: cannot remove `/proc/21853/fd/3': Operation not permitted

マスタリングTCP/IP RTP編
　http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/

って入門編読んだぐらいの知識でも理解できそうですか？

↑マスタリングTCP/IP 入門編の事です

お前が理解できるかなんて、誰がわかるってんだよ

切れすぎワロタw

RecallToyotaProtocol

最後はPriusだろ

APIスレでスルーされたのでこっちに貼ります
リモートのIPアドレスからコンピューター名を得る方法ありますか？
自分も相手もWindows(XP以降)です
正しくはコンピューター名じゃなくてUNC名ですが

2時間でスルーとかどんだけ自分勝手なんだって話だと思うが。

ってかこのスレ全然建設的じゃないな。
教える気がないんだったら煽ってないで黙ってろよ。

うるせえ

ある。でも聞き方が気に入らないから取り方は教えない。

お前にきいてねえよ。
他の奴、答えろ。

ある。でも聞き方が気に入らないから、オレも取り方は教えない。

やったことないけどWMIは使えないだろうか

サーバで、100クライアントからの要求を 100ms 毎に 1回受信
(1クライアントは 10sec 毎に1回要求送信)
し、DB検索後、応答を最大 100ms 内に返す時の、サーバーの
I/O 戦略 (下記 url 参照) は、一般的に、どのような形になるでしょうか？
なお、その他の処理に DB 更新処理があります。

参考：
Winsock Programmer's FAQ: Articles: Which I/O Strategy Should I Use?
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/articles/io-strategies.html

まず、C# で beginread() （上のページの非同期型ソケット？）を使用して
作っていましたが、その他の DB 更新に時間がかる等、高負荷時に、
要求を受信しても、beginread() が起動しない (スニファで受信確認)、
という事象があり、応答が 100ms を超えてしまいます。

コンテキストスイッチが原因と思われたので、socket.select() で、
受信後、DB 検索を threadpool を利用し、別スレッドで実行し、
受信スレッドは、常に受信を続ける等を検討していますが、
正しいのでしょうか？

応答上限 100ms は、馬鹿げていると思いますが、仕様なので、
なんともなりません・・・

環境：
サーバ：Win2008 server 32bit sp1, Xeon5500 x 2, 4Gb
クライアント：WinXP sp3, Core 2 Duo 7400, 2GB
開発環境：VS2008 .net FW 3.5 sp1

その仕様を作った奴にきいたら？
そいつはできるから仕様にしたんだろ

客先は、同じ内容を他社にも発注しており、
他社システムは 100ms 内になっているため、
苦しんでおります・・・

やりかた聞けよそいつに
客先にソースあんだろ？

IISなら速いよ

どーみてもボトルネックはDB操作。

0.1秒って考えれば結構長時間にみえてくる

FPSでpingが100以上だと致命的だな

100msって、単に通信だけなら相当に長い。
それがきつく感じるのは>>46にもあるけどDB操作があるからだろ。
通信周りをどうこう考える前に、DB操作が、せめて80ms以内にできなきゃ話にならん。
DB操作が並列処理で高速化できるなら通信まわりも並列化だろうが、
DB操作が並列操作でもスループットあがらない処理なら、通信周りだけ並列化しても意味が無い。

同期処理しなけりゃならないなら、NoSQL系の奴使うとか。
同期じゃなくて良いなら、要求をキューイングしておいて、別プロセスとかで処理すれば？

コネクションプールしてないとか
まさかね

他社は出来てるんだから遅い原因は>>41にあるという結論に至る。
>>51あるいはDBの設計が致命的にヘボい。

プログラミングに工数かけるくらいなら、50万くらいで買えるそこそこ高速なDBサーバ提案しろよ。

>>41
＞サーバで、100クライアントからの要求を 100ms 毎に 1回受信
＞(1クライアントは 10sec 毎に1回要求送信)
速攻クビにしたいレベル。

とりあえずサーバがDBを兼ねているとして、検索するだけで更新が無いし、
検索用にスレッドを作っておいて検索内容を受信したら投げてseteventでもして起こす。
そういうのにすれば良さそう。

他社で出来るなら、他社のシステム導入すればいいだけだしな。
遅いシステムしか組めない所はイラネ。

サーバー、クライアントプログラミングを勉強しております。
サーバー側でacceptで停止している場合はどうしたらいいのでしょうか?
クライアント側を再起動すると直るのですが。
サーバー側でどうにかしたいのですが、accept内部で待ちに入ってしまったら
どうしようもないのですか?

普通はacceptでブロックしないように、selectする。

recvとsendのソケットをわざわざ別タスクにする意味ってありますか？
一つのソケットでsendとrecvやってはまずいでしょうか？

どっちでも

タスクを分けられるなら分けたほうがいい

何故？

別タスクって何？二つのソケットっていうこと？だとしたらそんな必要全然ない。

>>62
二つのソケットつくるということです。タスクを別にして。
メリットってなんかあるのでしょうか？
設定の簡略化？

二つのソケットってディスクリプタが別のソケットってこと？
それサーバ側とクライアント側でどう二つのコネクションを確立するつもり？

UDPならコネクションいらないとおもいまして

どっちでもいいと思うけど、なぜ頑なにひとつのソケットでやりたいのかの方が分からん

二つのソケットつかってやろうとすると、なぜかうまくいかなかったので
ひとつでrawつかってるせいか。

送信と受信を同じソケットでやるさい、送信と受信のバッファみたいなのは別なのでしょうか？

例えば、

while{
send
recv}

でループするような処理の場合、recvを抜けたあとに大量にデータが送られてきて、
sendをしようとするも、送信するはずのデータが受信データがはいってきたことによって
送信できなくなるということはあるのでしょうか？

バッファとはソケットレイヤにあるものと考えて

UDPなんだかTCPなんだかはっきりしろ

ごめんなさい。UDPです。

疑問なんだけど、windosやmacが独自につかってるプロトコルを、
unixが受け取るにはどうしてるの？unixのtcp/ipでもないやつとか

unixは盗人が標準装備だから
あとは判るな？

すみません、詳しくお願い致します

ただのUDPのデータと、DNSのデータってどうプロトコルの違いをみつけてるのでしょうか？

ポート番号とプロトコル種別含めて、別々のプロトコルと区別するのでしょうか？
そうした場合、別のプロトコル同士としてドライバレベルで認識してしまうのでしょうか

同じUDPやTCPのデータであっても、セッション層やプロトコル層までいくデータでは、
recvの扱い方が違うのでしょうか？

>>74,75
意味不明。まずは質問できる程度の知識をつけてから出直そう

私の作っているチャットのサーバ側のプログラムは仮にクライアント、AとBがサーバに接続していて、
AがBにチャットを申し込むとAとBのスレッドを別々に作成し、お互いのスレッド内のみでチャットするという動作(希望)をします。
両者のスレッドでは自分のソケット宛にrecvをしていて
仮にクライアントAがBにデータを送ろうとするとA側のスレッドのプログラムだけを通ってデータが行くのか、
それともB側のスレッドのプログラムも通って行くのかが気になり
(A側のスレッドでBのソケットディスクリプタにデータを送る際、B側のスレッドでBのソケットディスクリプタでrecvをしているため。)
下記プログラムを作って試してみました。
(main関数ではほぼaccpetしてスレッド作るだけなので省略します)
続く

void *threadMain(void *socketer){
int recvSocket,sendSocket,bufLen;
char buffer[100];
FILE *fp;
struct socket *abbr = (struct socket *)socketer;
//Aが既にコネクションを確保していて、Bが確保すると抜ける
while(abbr -> flag == 0){
sleep(1);
}
//Aはabbr -> flag == 1の括弧内、Bは == 2の括弧ないの処理をする。
if(abbr -> flag == 1){
abbr -> flag++;
recvSocket = abbr -> socket1; //Aのソケット
sendSocket = abbr -> socket2; //Bのソケット
}else if(abbr -> flag == 2){
recvSocket = abbr -> socket2; //Bのソケット
sendSocket = abbr -> socket1; //Aのソケット
}

while(1){
bufLen = recv(recvSocket,buffer,sizeof(buffer),0);
buffer[bufLen] = '\0';
sleep(5); //Bを経由しているか確認するため。

printf("%d--%d--%s--%ld\n",recvSocket,sendSocket,buffer,(unsigned long int)pthread_self());

send(sendSocket,buffer,bufLen,0);
sleep(1);
}
}
続く

私の考えではもしもBを経由するなら
クライアントAがデータ送信→スレッドAで受信、Bのソケットに送信→スレッドBで受信、Aのソケットに送信→無限ループ
経由しないなら
クライアントAがデータ送信→スレッドAで受信、Bのソケットに送信→クライアントBに届いて終了
となるはずでした。

結果的にBは経由せずにデータが送られるということがわかったのですが
(A側のスレッドでsleep(5)が終了後、クライアント側にデータが送信されたため)
なぜか、下記のように無限ループが起きてしまいます。
5--4--abc---1225315472
4--5-----1216922768
5--4-----1225315472
4--5-----1216922768
5--4-----1225315472.....

クライアント側は送信側はデータを送信した時点で、受信側は受信した時点で終了しているのでデータは何も送信していません。
また、最初の送信以降はデータabcが消えています。なぜこのような動作をするのでしょうか。
長々とすみません。よろしくお願いします。

fork

recvってどこの層でデータをとってるのでしょうか？

httpプロトコルとか、トランスポート層より上にあるプロトコルの場合、
どうデータを処理しているのでしょうか。

ソケットに対しての O_SYNC って何か意味を成すの？

winsockについて質問です。よろしくお願いします。

まず現象を説明します。
クライアントはWindowsのゲームアプリケーションで、2本スレッドが走っています。

片方は、連続的に映像を描画しています。
もう片方は通信を担当しており、ノンブロッキングモードのSOCKETを監視しています。
秒間60回程度「recv()を監視し、受信バイト数をデバッグウインドウに出力」するスレッドです。

サーバーからデータをsend()すると、クライアントのデバッグウインドウにすぐさま何バイト受け取ったかが表示されます。
（1回のrecvで受信しきれるとは限らないのはもちろんですが）

問題は「映像の描画」の負荷が重くなった時に起きます。
サーバーがsend()してから、受信されるまでの間隔が5秒〜20秒くらいとものすごく遅延するのです。

最初は、描画負荷によって、通信監視スレッドが止まってしまっているのかとも思いました。
ですがループ自体は軽快にまわっています。（0バイト受信というメッセージが、秒間60回吐かれ続けています）

質問は
・これは良くある現象であり、プログラムが間違っているわけではないのかどうか
・解決する方法はあるのか（一応映像の描画は、フレームスキップやらSleep(1)を毎ループ挟んだりやらしたのですが改善せず）
です。
アドバイスよろしくお願いします。

>>83
ちゃんと秒間60回吐かれ続けてるの？
ここでログとって時間調べた方がよくね？
あと、念のためマジで受信してるかパケットログ取ろうぜ

>>84
はい、60回については通し番号やWindows時間とともに吐かせて確認したので、ループ自体は正常にまわっているようです。

すいません「パケットログ」というのが分からないので、よろしければ教えていただけますでしょうか。
低レベル層でパケットの受信が行われたかを、ツールか何かで見る。ということでしょうか？
教えていただけると幸いです。

余談です。
勝手な素人考えでは
「パケット自体はもちろんすぐ受信されているのだけど、
　CPUパワーを食いすぎており、
　アプリケーション層に渡すまでの処理が超時間かかってしまている」

のかなと。
でも、そこまですさまじく重い（Windows全体がカクつく）ほどではない状態でもなるです

読みこんでないデータがあって通信バッファが空くまでまってるんじゃねーの?

>>84
＞send()してから、受信されるまでの間隔が5秒〜20秒くらいとものすごく遅延
これは明らかに何かが破綻しているね。

単純に時間当たりの通信量がシステム能力に対して多すぎて
間に合ってないってことは？
そうでなければ多分受信スレッドのバグだね。

パケットログはWireSharkをインストールする。通信系のソフト作る場合
パケットログをいつでも採れるようにしておくのは必須事項。

UDPw

アンカー間違ってた。>>83ね。

ソケットのバッファって、どうなってますか？受信と送信用それぞれ別々？

は？

君が期待しているようなバッファはない

>>90
一般的にはバッファというのはカーネル内での制限値の様な物。　必要があったら
配分して溜め、規定値を超えたら残りは状況に応じた処理をする。　受信側と送信側は
全く別。　

recv側：
　　udp 捨てる
　　tcp 窓を０にして送信側をブロックする

send側
　　sendのコールがブロックされる（バッファに空きが出来るまでコールが終了しない）
　　nonblockingという場合はもうちょっと複雑。
　　　
バッファの容量はシステム設定やソケットのオプションで変更出来る。

>>90
setsockopt
SO_RCVBUF int Specifies the total per-socket buffer space reserved for receives. This is unrelated to SO_MAX_MSG_SIZE and does not necessarily correspond to the size of the TCP receive window.
SO_SNDBUF int Specifies the total per-socket buffer space reserved for sends. This is unrelated to SO_MAX_MSG_SIZE and does not necessarily correspond to the size of a TCP send window..

>>80
pthreadじゃ出来ないんですか？
ソケットじゃなくてpthreadの方の問題ならスレチになってしまいますが。

>>93
UDPの場合、
sendやrecvをコールすることによって、バッファの中をとっていくわけですよ。
逆にコールしないと、recvではデータが上書きされていくような感じなのでしょうか？
sendはバッファに空きが出るまでコールが終了しないということですが、
その間、他の処理はできないというわけでしょうか？
だとしたら、sendのタイムアウト値みたいなものはないのでしょうか。
また、sendのバッファを一度クリアしてから、sendをコールするということはできますか？

UDPであれ、TCPであれ、RAWであれ、１つのソケットで送受信ができるバッファが用意されるのでしょうか？

1500バイトぐらいはあるんじゃね

>>97
ソケットごとにな！

ソケットにO_SYNCつけてみたけど、なにも変化なかった。
これって単に無視されてるだけ？

変な質問繰り返してる奴って同一人物かな

それ、2ch病の初期症状です

>>101
>>82=>>100=俺です。
そんなに変な質問だったかな。

とっても。

どうやってソケットにO_SYNCつけたの？

便乗質問させてください

以下のページのように、小さいデータをやり取りしたときに、
アプリケーションから send() した後、OS でバッファリング
されて一定時間送信されないということは他にもあるのでしょうか？

現在作成中のサーバー・クライアントシステムで、クライアントの
send() 後、サーバの非ブロッキング受信の発生が 200ms 程度、
遅れることがあり、困っています。
rcvbuf サイズを小さくしたところ、大分、ましになったのですが、
rcvbuf サイズは、受信の遅延に関係するものなのでしょうか？

設計上の問題 - Winsock と TCP 経由で小さなデータ セグメントを送信する
http://support.microsoft.com/kb/214397/ja

モゲラのクロスドメインって何？

nagle意外に遅延させるものってあったかなぁ？

匙をnagle

>>108
ないんじゃね？200msもドンピシャだし。

>>108
Delayed ack (rfc2581)。 Nagelの方は標準のソケットオプションTCP_NODELAYで停められるけど
delayed ackは無いので停められない。　一度どうしても必要があったのでTCP_NODELACKという
オプションをLinuxカーネルに作り込んでむりやりdelayed ackを解除した。

>>86-87
返事が遅れてすいません。

通信しているデータは10バイトとかそんなレベルです。
遅れて届くという言い方が曖昧でした。

例えば5秒間隔で3回通信すると、概ねクライアントには5秒間隔で3度にわけて届きますよね。
（通信データが十分小さければ）

これが、私の「非常に重い環境で起こるおかしな挙動」状態だと、10秒程度何も届かず、
その後5秒間隔で3回届くのです。

通信スレッドの仕組みですが、非常に簡単で

while(true)
{
Sleep(16);
recv(buffer);
output(timeGetTime(), buffer);
}

こんな感じです。（正確性は今回の実験では関係ないので、単にSleepです）

WireShark ありがとうございます。
こちらを使ってもテストしてみます

>>111
TCP_QUICKACKじゃだめ？

なんでSleepなんかしてんの？

>>113
man tcp(7)の説明だとそういうふうに誤解しちゃうね。　自分も最初はそう思ったのだが
ここの説明で理解した。　

http://articles.techrepublic.com.com/5100-10878_11-1050771.html

要約すると、ソケットが作られた時にはTCP_QUICKACKは1に設定されているが、
最初のACKが行われるとすぐにこれが0になる。　これはクライアントの場合は
connectしたとき、帰って来たSYN ACKを直ぐにACKする（送るデータを待たない）。

しかしクライアントが直ぐにデータを送るという状況だったらこのpayload無しの
ACKは無駄になる。　そこでソケットを作った時にTCP_QUICKACKを０に設定すると
SYN ACKは直ぐにACKされない。　しかし次にデータを送るとそのdatagramで
SYN ACKがACKされ、パケットが１個節約出来る。　

>>106はWindows環境での話みたいだから遅延ACKはレジストリで
無効にできるでしょ。
ただ「rcvbuf サイズを小さくしたところ、大分、ましになった」
ってあるので遅延ACK問題じゃないような気がするけど。
いずれにせよ、こういうのはパケットログを取れば原因は大抵分かる。

>>111, 113, 116
ありがとうございます。

遅延 ACK は、TcpAckFrequency のことだと思います。
とりあえず修正はしています。

ところで、アプリでデータ受信イベントが起こるのは、
受信後、送信側へ ACK を送信してからなのでしょうか？

>>117
そうです

某のTCP/IPスタックがおバカだから

すいません。
理由がわからないので、解説サイト等があれば、
教えて頂けないでしょうか？

受信が小さくなったからこまめにack飛ぶようになったとかじゃないの？

定期的に送受信をUDPでおこなっているのですが、
（他から絶えずデータが送られて来ている中で）
稀に送信が一瞬とまり、再開後の最初のパケットの中をみると特定の所だけデータがおかしくなっています。

定期的に送信している中、データの送信が一瞬とまる原因って何か考えられますでしょうか？

UDPだから

UDPなら一瞬どころか何度止まっても文句言えんぞ

NICのバッファが溢れて止まってるように見えるんだよ
UDPだからというわけではない

>某のTCP/IPスタックがおバカだから

linuxとかからping実行してみれ

>>118って本当なの？

>>128
本当です

>>128
合ってるが、ACKはすぐに送信するかは判らない。
こちらの送信データが揃うまで待つかもしれない。
ただし届いた分のデータについてはアプリに渡してしまっても良い。
異常ケースとしてACKを送信しても相手に届かない場合もあるが、
それでもACKまでのデータは確定しているから、
その場合起こる再送信でもACK以前のデータは読み捨てられる。

補足するとACK送信はこちらの送信データが無いケースでは、
タイムアウトか受信ウィンドウサイズの限界まで待つかもしれない。
TCP通信においてレスポンスを重視する場合、アプリケーション側で
定期的に相互にデータを送り続けてスタック上のバッファを吐き出させる
戦略を取った方が良い。
片方が無言だったりするとスタックのアルゴリズムまかせになる。

>>130
「届いた分のデータについてはアプリに渡してしまっても良い」
筈なのに、（というか渡すべきでしょ？）WinSockではACKを送信
した後になってはじめてアプリに渡すと>>118は言ってると思うのだが。
これは信じ難いので。。。
本当にそんな馬鹿な作りになってるのか試したいんだけど今試せない。。。

ここは納期なんてないから
いつまでも待ってやるから
試してからまた来い

>>132
それは前後しても構わないし、「後か先か」に意味がまったく無い。
ACKが相手に届くかどうかなんて知ったこっちゃないので。

>>125
周期的に送ってるのに稀に数回分も連続してとまるのでしょうか？
また復帰するのも謎です
送受信のバッファが別なら受信ならともかく送信までいかないのが気にかかります

基本がなってない気がする

>>135
ネットワークプログラミングで重要なのは問題の切り分け。　結局wiresharkは使い始めたの？

>>133
はい。試しましたよ。
WindowsXP SP3でシステムのデフォルトの遅延ACKの設定にし、
クライアント側から１秒周期でパケットを送り、サーバ側で
パケット受信毎にミリ秒単位の受信時刻を表示するようにし
て、Wiresharkのログと付き合わせましたが、アプリには
ちゃんとデータパケット受信時に渡っていますよ。
遅延ACK送信時じゃなく。
そうじゃない環境（Windowsのバージョン?）があるんですか？

>>122
TCPを使いなはれ

>>136
基本より深い問題なきがしないこともないですが、
UDPだとソケット自体がおかしくなることもあるってことでしょうか？

>>140
ありまくりやがります

ソケットが途中でこわれる原因は何でしょうか？

スタック部分が途中でおかしくなったら、ソケット再起動してもかわらないですよね

ソケットは壊れねーよ。

同じことを書こうとしたら先人が・・・

自分のプログラミングのまずさをスタックがおかしいせいに
する癖がついている奴がいるな。ソケットが壊れるってｗ

基本がわかってないから深い問題のような気がするだけなのに

>>142
壊れるのはパケット

ソケットが壊れるなんてちょっとないよね？と思ってたのに
>>141が壊れるよと言うもんだから

最近打ち合わせでは分かり切ったことは飛ばして話を進めているのに
知識として持っててあたりまえのことを質問する馬鹿が増えた

http://pc12.2ch.net/test/read.cgi/tech/1268699491/483
コピペ化する予定ですか？

ソケットは本当に壊れることがないのだろうか

>>97
それは実装依存
プロトコルに違反しないならなんでもOK

>>151
普通はsocketが壊れるより先にまずpingが折れると思う

pingがおれるとはどういうことでしょうか？

CPUだろ
pinとpingをかけたか、素で間違えているか

ネットワークプログラマならマイコンのIOピンを自分でON/OFFして
シリアル通信くらいしたことないとな

TCP/IPじゃなくてシリアルですか

その辺を混同して設計できるのがソケットプログラミングの強みだろ

>>158
ｋｗｓｋ

でもソケットのスレじゃなくてネットワークプログラミングのスレなんだよね

惘網綱綳線縲織

GET / POST で　HTTP リクエストするけど
相手のサーバによっては拒否される？

どっちかというと
クライアントによっては拒否される
が正しいと思う

受信割り込みを一時的に受付ないようにするにはどうすればよいのでしょうか？

AcceptExなどのmswsock.dllに実装されている関数を、
WSAIoctlで取得した関数ポインタで呼び出すことが推奨されていると以下のページで書かれています。
ttp://eternalwindows.jp/network/winsock/winsock06c.html

実際にAcceptExを直接呼び出しても表面上は特に問題なく動作しているように思えますが、
どのような問題が発生する可能性があるのでしょうか？
御存知の方は教えて頂けると幸いです。

>>165
差し換わるかもしれんじゃん。

>>165
レス有り難うございます。
差し換わるというのは、コンパイル時に直接記述されたAcceptExのアドレスが、
mswsock.dllの変更やバージョン違いによってアドレスが変わってしまうという解釈で宜しいのでしょうか？
dllに関しての知識が不足してるので、見当違いでしたら申し訳無いです。

すいません、レス番ミスです。
>>167 >>166

>>167
mswsock.dllじゃなくなるかも。という事だろう。

>>169
そういうことでしたか。
教えてくださった方どうも有り難うございました。

recvfromって受信割り込みで動くのでしょうか？
デバイスドライバへの割り込みがきたあとに、recvfromをすることによって
データをとれるのでしょうか？
デバイスドライバへの割り込みを禁止してしまうと、データはrecvfromでとれないということ？

http://pc12.2ch.net/test/read.cgi/tech/1205795434/780

winsockで、アクセプトしてるネットワークカードの
１２７．０．０．１でないＩＰを取得する方法はありますか？

>>173
アクセプトしているなら接続元のIPを取得できる

>>173
getsockname

IPってゆうな。クズ。

>>176
っ□

IPが駄目ならXPで、それでも駄目なら申し訳ないが:Pになる

ゆうな、なんて書くなよ恥ずかしい

ゆうなってゆうよ
はずかしがったらいかん

Windows XPのTCPをオリジナルのTCPに変更したいのだが、
WinSockとかWinPcapとか使えば可能でしょうか？

は？

不可能。

可能。

Winsockの呼び出しをフックするか、
winsock.dllのラッパーを作れば良さそうですね。
ありがとうございました。

ネトゲに割り込むのかな？

質問です。

WinSockで自分のPCのグローバルIPアドレスを取得するには
どうすればいいでしょうか？

http://checkip.dyndns.org/

>>187
一般的には、UPnPを使うことになると思います。
winsockでゴリゴリ書いてももちろんかまわないのですが、COMインターフェースが
用意されているので使ってみてはどうでしょうか？

NAT越しに通信してるときに
NAT後に利用している送信元ポート番号を知る方法ない？
通信相手に教えてもらう以外で。
あったら教えてください。

ない、プロトコルを学ぶべき

>>191
プロトコルから外れた標準外の方法でもいいんだけど。
まぁ確かにライブラリを使うってだけの話じゃないから、
難しいってのはわかるよ。

横からですが、それできちゃったらNATの意味ないんじゃ・・・・
クラッカーとかはどうか知らんけど・・

NATの内側同士でP2Pするソフトがあるから
それのソース見て勉強しなさい

Winsock2の質問ですが、
ソケットエラーが返ってきた場合でもclosesocket()は必要でしたっけ？

>>195
ソケット作成時以外なら要るだろう。

>>196
ありがとうございました。

>>193
知られちゃダメなNATの意味ってなんだよ。UPnPなんか許せない死ねという主張か?

>>190
NATトラバーサルとかそういうこと？

ネットワークについての質問です。
皆さんの力をお貸しください。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1440449509

>>200
普通に共有フォルダでいいだろw

>パソコン部の高校での文化祭で展示したいものがあります。
>それが、パソコン2台を接続してハードディスクなどを共有することです。

どこの国の人だよ

>>202
パソコンの中、つまり仮想世界なんです

仮想世界の高校での文化祭で展示したいものがあります。
それが、パソコン2台を接続してハードディスクなどを共有することです。
パソコン2台とは1台は仮想世界のパソコンでもう一台は現実世界のパソコンです

一部といわず、全部仮想世界の出来事にすればいい
死んでるように見えますが、仮想世界では生きてます

matrixの世界だな

君が現実と思っている世界は実は仮想世界なんだ
神の創った仮想世界、それが君達の世界なのだよ

今度はどこの漫画なんだろう。
最近チェックしてないからよく分からん。

　　　　　　　　　　　　　　　　　　　　　＿　　　　 　 　 　 　 　 　 （　　信.　 信 　 余　 　）
　　　　　　　　　 　 　 　 　 　 　 ,r'⌒　　｀ヽ　　　　　　　　 　 　 ）　　じ　　じ　　は　　(
　　　　　　　　　　　　　　　　　 (　(　 ,．　 ┴─　．　　 　 　 　 （　 　た 　 ぬ　　 　 　丿
　　　　　　　　　　 　 　 　 　 　 ゝ　 ´　 　/　　 　 ＼　　　 　 　 ）　　く 　 　 　 　 　 （
　　　　　　 　 　 　 　 　 　 　 　 ｢　　 　 厂ｯヘ￣＼ ',　　　 　 （　 　 な　　　　　　 　 )
　　　　　　　　　　　　　　　　　　ﾘ 　 　./ 　,==≧v ,ィ}　　 　 　 ﾉ　 　い　 　 　 　 　 /
　　　　　　　　　　　　　　 　 　 /　　　 { 　〃 　　j ｢`'}　　 　　　＼　　 　 　 　 　 　 ﾉ
　　　　　　 　 　 　 　 　 　 　 /　　　　.|　 r--､_　ｲ　}　　　　　　　ゝ─っ　　．-─'′
　　　　　 　 　 　 　 　 　 　 ,ｲ　　　 　 | 彳￣` ‐.ﾏ}ﾉ　　　　　 　 --==彡 '　
　　　　　　　　　　　　 　 r'´ :l　　＼　 .|　{＿,,_ 　//
　　　　　　　　　　　＿／　　 ゝ.　　 ＼＼　 　 `´/
　　　　　　　 ／￣　　　　　　　　　　　　ミ≧rrrｲ
　　　　 　 ／　　　　　　　　　　　　　　　　　ヾツ＼
　 　 　 ／　　　　 　 　 ＼　　　　　　　　　 　 　 　 ＼
　 　 ／　　　　　　　　　　 ＼　　　 　 　 　 　 　 　 ﾉ. ＼
.　／　　　　　　　　．-‐＝＝＝ｷﾐ､＿＿＿＿＿∠彡=≧
. '　　　　　　　／￣ヽ 　 　 　 　 ∨://///V/////　/ ￣＼
　　　　　 　／　　　 |　　/￣￣￣∨//////////　/　　　　＼
　　　　　／　　　 　 | 　/　r──-く＾V:///////　/／　 　 　 ﾍ

素朴な疑問なのですが、Winsockの
WSAAsync
は何の略なのでしょうか？

WSはWinSockな気がしますが、AAsyncとは…？
syncはsynchronizeでしょうが、それならAASyncとなりそうなもの。
そもそもＡＡって？

WSA: Windows Sockets API

WinSockApiASynchronous かな

WinSockAPI Async

ASync のAは一体・・・

アシンクロナスだろ
非同期っつー意味

おお、Asynchronous　で非同期って意味か

うわあ、ネタじゃ無かったのか。

Sを大文字にしてる香具師は馬鹿

>>216とか>>216とか>>216とか
の事か?

質問よろしいでしょうか
gethostbynameは即座に処理が返ってくるとは限らないので、なるべく
WSAAsyncGetHostByName　を使った方が良い。

ということだったので使ってみているのですが、
実験として「名前解決に数秒かかる」状態を試してみたいと考えています。

どのようなアドレスを指定すれば、そのような挙動になるでしょうか？
・存在しないアドレスを指定してみる
・LANケーブルをひっこぬいた上で、存在するアドレスを指定してみる
・LANケーブルをひっこぬいた上で、存在しないアドレスを指定してみる
と試してみましたが、どれも1秒もたたないうちに「失敗」となりました。

壊れた(Timeout長めにポートフィルタされた)DNSに登録されているドメインのFQDNを指定する

>>218
存在しないLAN外のアドレスを指定するといいよ

>>219
となると、自前でDNSサーバーを立てなければなりませんね。
仕組みは知っているものの、気軽に立てられるものなのかなどはサッパリです。今ぐぐって勉強し始めました

>>220
存在しないアドレス（LAN外です）を指定してみたのですが、1秒立たずに失敗で返ってきました。
私自身も、仕組み上長い間さまよってくれると期待していたのですが・・・。

試してみたアドレスは以下の通りです。キーボードをめちゃくちゃに打ったものです。
www.fadbiouhfewrw.com
プログラムの間違いも考え、試しにブラウザでも開いてみようとしましたが、こちらも1秒立たずに
「存在しないサーバーです」となりました。

>>218
実験するPCのファイアウォール設定でTCP53行きパケットを破棄しておいて実行する
(REJECTじゃなくてDROPね)

LAN内の存在しないアドレスをネームサーバとして設定する。

>>223
10秒くらい稼げるね

>>222-224
アイデアありがとうございます。

>>223
こちらの手法で試したところ、10秒程度の時間無反応にすることができました。
ありがとうございます。

他の人がやる時のために記述しておきます。WindowsXPです。

・コンパネで「ネットワーク接続」
・「ローカルエリア接続」を選択して開く（接続の仕方によって、多分名前違うでしょう）
・プロパティ
・インターネットプロトコル（TCP/IP）を選択し、プロパティ
・「次のDNSサーバーのアドレスを使う」をONにし、優先DNSサーバーに存在しないローカルIPアドレスを割り振って「OK」ボタン
・ウインドウが1つ閉じるので、あらためてこちらも「OK」ボタンを押す（押さないとまだ設定が反映されていませんでした）

この状態で実験。

やっぱさ、任意の通信障害を起こせるHUBってほしいよね。

>>226
dummynet

linuxならnetem、freebsdならaltq使えば、大抵のエラーは起こせるだろ。
fcs壊すようなL2エラーとか、ワイヤレート欲しいとかなら専用ハードになるけど。

通信遅延とかそういう現象も全部試験したいなら、GtrcNETという装置があるぞ

>>229
netemやdummynetは遅延出来るよ．

長いLANケーブル使えばいいじゃん

箱ごと何巻も繋いでるのを見たことがあるな

まずブラジルに親戚を作ってだな・・・

意外と近くて遠い国は北朝鮮とか

相談よろしいでしょうか。

gethostbynameに相当する関数は、
・gehostbyname
・getaddrinfo
・WSAAsyncGetHostByName
の3つだと思うのですが、少し悩んでいます。

と言いますのも
SOCKET SocketConnect(address, port, timeout);
こんな感じの関数を作りたいのですが、上記3つはどれもタイムアウトを設定する術が無さそうなのです。

connectは
::WSAEventSelect(socket, hEvent, FD_CONNECT);
こうすることで、タイムアウト付きで呼び出せているのですが…。

何か良い方法はありますでしょうか？
（WSAAsyncを使うのが正道だとは思うのですが…）

別スレッドでgetaddrinfoを使って問い合わせる。 MSDNでも推奨

http://msdn.microsoft.com/en-us/library/ms741522(VS.85).aspx
Note The WSAAsyncGetHostByName function is not designed to provide parallel
resolution of several names. Therefore, applications that issue several requests
should not expect them to be executed concurrently. Alternatively, applications
can start another thread and use the getaddrinfo function to resolve names in an
IP-version agnostic manner. Developers creating Windows Sockets 2 applications are
urged to use the getaddrinfo function to enable smooth transition to IPv6 compatibility.

サーバー側のWinsockプログラムで質問です。
特定のIPからのアクセスを「成立させずに却下する」ことはできないでしょうか？

現在はとりあえず成立させたあと、IPを調べ、NGユーザーなら即座にshutdown & closesocket しています。
つまり、ユーザー側はconnectに「成功」し、即座に切断されます。

ここをconnectにそもそも失敗させてやりたいのです。

そんなもんスイッチにやらせりゃいいじゃん

スイッチ？とはなんでしょう？

ははは
ご冗談を

netsh

>>239
ルーター、サーバーのファイアウォールでしっしっ

アプリケーションでやるのが目的となります。
何か方法があれば教えていただけますでしょうか。

FWもアプリケーション

すげえ揚げ足取り

IPってゆうな。クズ。

>>243
acceptする前にackを返すので無理です。
SYN FLOODがなぜ未だに有効な攻撃手段なのかを考えればわかると思いますが、
アプリ側でやれる事といえばせいぜいBACKLOG数を調整するくらいです。

何度このリンクを貼ればいいのか
http://ruffnex.oc.to/kenji/text/fire_a/

何回目？

accept拒否はWSAAcceptのlpfnConditionを使えば出来るんじゃないの？

>>237
可能。winsock限定になるが。
MSDNで「SO_CONDITIONAL_ACCEPT」と「WSAAccept」を参照すべし。

>>249
もう二度目だよ
いい加減にしてほしい

>>248
UNIX版も作って！

>250-251
ありがとうございました。
無事できました。
しかしこれ、情報少ないですね。
気になる点としては

SO_CONDITIONAL_ACCEPT ソケット オプションを使用して通信するプログラムを使用すると、ネットワークのパフォーマンスが低下する
ttp://support.microsoft.com/kb/328264/ja

↑これと、後は「CF_REJECT」を返しても2〜3回程度WSAAcceptが反応することでしょうか。
断ってるんだからあきらめろ！
と言いたいところですが、断られたことが相手に通じるまでの間に、再要求が何度も来ているという感じでしょうか？
（もちろん、クライアントは1度のconnectしか呼んでいません）

>>254
KBの328264についてはXP Service Pack 2で修正済みとあるよ。
ただそれでもSO_CONDITIONAL_ACCEPTを使わない場合と比較すると
一定時間内に受け付け可能な接続数とかは低下するだろうけど。

＞「CF_REJECT」を返しても2〜3回程度WSAAcceptが反応することでしょうか。
えっ？マジで？
サーバからちゃんとRST出てる？

>>255
レスありがとうございます。

RTS　というのについてこれから勉強させていただきますが、まずは自分が書いたソースを転載しておきます。
使い方間違えている可能性も高そうですので。

unsigned long flg = TRUE;
setsockopt(sck, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, (PSTR)&flg, sizeof(flg));
listen(m_sckListen, 10);

while(true)
{
struct sockaddr addr;
int len = sizeof(addr);
SOCKET user = WSAAccept(sck, &addr, &len, CheckFunc, NULL);
printf("%d\n", user);
}

int CALLBACK CheckFunc(引数省略)
{
return CF_REJECT;
}

こんな感じです。（感じですというか、プロジェクトからコピペしました）
この状態でクライアントからconnectすると、WSAAcceptが２〜３回反応します。
サーバーとクライアントは同PC上で動作させ、localhostへ向かってconnectさせています。

connectを呼ぶのは1度だけ。結果としてはもちろん「拒否」され、connectは失敗します。

反応というのはprintf("%d\n", user);の出力があるという事か?
その時のuserの値は?

>>257
はい、printfが２〜３回反応します。ほとんどの場合3回です。
値は -1なのでINVALID_SOCKETです。

>>256
調べたけどWinsockではSYNに対するRSTはクライアント側で
無視されるみたいですね。>>248の方が良いかも。

まあ>>248でもクライアントは３回SYN出すわけだけど。

>>254
3回SYN出すのはwindowsが糞仕様だからだ。実際に1つのconnectで3回接続試してる。
unixからのconnectならば1回しか出ないはずだ。

↓にあるようにレジストリのTcpMaxConnectRetransmissionsを0にするがよい。

http://support.microsoft.com/kb/175523/
http://support.microsoft.com/kb/933805/
http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx

とりあえず、正常な動作だということで安心しました
細かくありがとうございました。

以後同じことをやる人は、
setsockopt(sck, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, (PSTR)&flg, sizeof(flg));
は、listenの前にやらなければならないことに注意してください。

マニュアルにもかなりさらっと書いてあって、最初見逃して頭ひねりましたので

こういう質問者ばかりだと、答える側も嬉しいのう

すいません、また迷い込んでしまったもので相談させてください。
262です。

CheckFunc内で相手のIPやホスト名を見て、許可したりしなかったりとやりたいのですが、
ホスト名をとるためのgethostbyaddrは時間がかかることがありますよね。

なので名前解決中に次の人のチェックへ移行しようと、1人目にはCF_DEFERを返しました。
と同時に、スレッドで逆引きを開始します。

しかし、次のWSAAcceptでは、先ほどCF_DEFERを返したはずの接続要求をまた取得してしまいました。
2つ目の接続要求が来ている状態にも関わらずです。

・プログラムは、>>256のものを改造。CheckFuncの中で「接続要求元IP」をprintfし、return CF_REJECT を CF_DEFERにしただけです。
・2か所のクライアントから、同時に１つずつconnectされている状況
・どれだけ待っていても、片方のIPのみが延々とprintfされます
・CF_REJECTを返すように書き変えた場合は、きちんとWSAAcceptが2つの要求を交互に取得します。（もちろん3回ずつ）

現状資料をひっくり返していますが、どうも「後回しにする」方法が見つかりません。
やはり妥協して「一旦は接続を受け入れ、その後身元調査。許可されたら送受信を行う。許可できない身元だったらclosesocketする」
という形にしたほうが良いのでしょうか。

元々が「接続させたくないIP or ホスト名からの接続要求をはじいて、そのクライアントのconnect自体を失敗させたい」から始めた調査なのですが…。

あらかじめ特定のIPがリストアップされてるなら
フィルタしてしまうのが一番良いと思うんだが

やはり>>248だな

IPってゆうな
これでいいですか？　＞いつもの人

文脈で判るものにいちいち文句たれるのは異常者

ホームページじゃないのにホームページとかな

>>264
例えば受け入れ可否を判断するのにホスト名文字列とパターンマッチ
しなけりゃいけない様な場合とかフィルタするのにDNS照会が必要な場合は
「一旦は接続を受け入れ、その後身元調査。許可されたら送受信を行う。許可できない身元だったらclosesocketする」
の方が何かと安全だと思いますよ。
それとも他に何か良い方法があるのだろうか？

ＩＰと言うなと言ってるやつが何を意図してるのかさっぱりわからんので
解説よろしこ

IPはインターネットプロトコル。
IPアドレスと言え。

IPってゆうな。クズ。

　　　 　 ,―ヽ＿（（（（（＿、―
　　　,／　　ノ　　　　　　　ヽ　　~＼
　 ／　　 ノ　　　ＩＰＡ　　　　ヽ　　　~＼
／　　　ノ　　　　　　　　　　　ヽ、　　`ヽ
|　　　 ﾉ /￣＼　　　／￣~ヽ　ヽ 　　 i
|　　 ノ　　　　　　　　　　　　　　|　　ノ
＼　 |　　＜●＞　　＜●＞　 （　 ）
　＼ |　　　　　 ｜　|　　　　　　 i /
　 　 |　　　　　 /　　ヽ　 　 　 　ﾚ
　　　i　　　　　（●_●）　 　　　 /　　
　　　 i、　　　 ,-――-、　 　・ /
　　　　i、　　<（EEEEE）>　∵/　　　　どういたしまして
　　　 　 i、 　＼　　　.／　　/
　　　 　　 ＼ 　 ーー　　 ,ノ　　　　　　　
　　,,.....イ.ヽヽ、ー-―一ノﾞ-､.
　　:　 　| 　';　＼_____ ノ.| ヽ　i
　　　 　 |　　＼/ﾞ（__)＼,| 　i　|

>>272
なるほど。
友達とか仕事やらで
関わりあいたくないタイプだということは分かった。

>>265
*.dion.jp　とかでNG設定する機能を作りたいものでして

>>270
CF_DEFER が「順番待ちの列の末尾に並ばせる」という機能であれば、現状の仕組み（>>256）でいけそうなのです。
DNS照会中に、他ユーザーまで待たされていまうのが問題なので。
「何かと安全」ということは、CF_?で拒否や許可をする方式は、何か危険性がありそうなのでしょうか？

>>276
危険というかCF_DEFER使った場合のシステムの動きがよく分からないから。
>>264の
＞しかし、次のWSAAcceptでは、先ほどCF_DEFERを返したはずの接続要求をまた取得してしまいました。
＞2つ目の接続要求が来ている状態にも関わらずです。
ということは一旦CF_DEFERを返したらその接続要求にCF_ACCEPTかCF_REJECT
を返すまで他の接続は受け付けられないようになっているんじゃないのか？
と思えるし、その状態で１つ目の相手がリトライした場合どうなるのか？とか。

うまく制御出来たら教えてください。

知っているわけでも、アドバイスできるわけでもないなら、質問者や場を混乱させるなよ・・・

解決法は知っているがIPと呼ぶ質問者には教えない事にしている。

>>279
よろしくお願いします。

CheckFunc内で相手のIPアドレスやホスト名を見て、許可したりしなかったりとやりたいのですが、
ホスト名をとるためのgethostbyaddrは時間がかかることがありますよね。

なので名前解決中に次の人のチェックへ移行しようと、1人目にはCF_DEFERを返しました。
と同時に、スレッドで逆引きを開始します。

しかし、次のWSAAcceptでは、先ほどCF_DEFERを返したはずの接続要求をまた取得してしまいました。
2つ目の接続要求が来ている状態にも関わらずです。

・プログラムは、>>256のものを改造。CheckFuncの中で「接続要求元IPアドレス」をprintfし、return CF_REJECT を CF_DEFERにしただけです。
・2か所のクライアントから、同時に１つずつconnectされている状況
・どれだけ待っていても、片方のIPアドレスのみが延々とprintfされます
・CF_REJECTを返すように書き変えた場合は、きちんとWSAAcceptが2つの要求を交互に取得します。（もちろん3回ずつ）

現状資料をひっくり返していますが、どうも「後回しにする」方法が見つかりません。
やはり妥協して「一旦は接続を受け入れ、その後身元調査。許可されたら送受信を行う。許可できない身元だったらclosesocketする」
という形にしたほうが良いのでしょうか。

元々が「接続させたくないIPアドレス or ホスト名からの接続要求をはじいて、そのクライアントのconnect自体を失敗させたい」から始めた調査なのですが…。

unixならそういう場合preforkしてacceptを並列で待てば終わりなんだが、
windowsはスレッドorプロセス毎に並列でacceptってできないんだっけ?

>>281
そもそもunixならaccept以前にSYN/ACK返す方法（一旦受け入れる）しかないでしょ。

>>282
方法が無いわけではない

またおまえか

>>280
IPアドレスと正しく呼んだので教えよう。

while (select()) {
if (fd_isset(listening_socket)) {
CreateThread(accept_func, listening_socket);
}
}

>>285
試してみましたが、スレッド側で「CF_REJECTかCF_ACCEPTを返すWSAAccept」が制御を返さない限り、
select()で「次のコネクト要求来たよ」という反応が出ないようです。

>>256でいうCheckThreadの中で::Sleep(10000);として試してみました。

やっぱりか。

XpだとCF_REJECTしても、REFUSEではなく接続後即切断。

>>286
そういう挙動なら、SOCK_RAWで監視するスレッドで先読みしておけば少しは改善する。
時間のかかるのが先に到着してしまったなら、回避出来ないけど。

>>288は嘘だった。

時間のかかるのが来た時に、それの影響を受けないようにしたいってのが質問の肝なんじゃね？

プロトコルスタックレベルの待ち行列のようだから、プロセス分けてもダメだろうな。

結局のところ、コネクト許可してからはじくしかなさそうだね

linux上で、HTTP通信の内容をすべてチェックしてパケットを通過させる、させないを制御したいんですが
なにを使って実装するのが一番簡単ですか？

例をあげよ

例えば、URLに特定の文字列が含まれるリクエストがきた場合は、
そのパケットを破棄して、かわりにエラーを返すといったことをしたいです。

なので、ネットワーク上を流れるすべてのHTTPのパケットを監視し
内容をチェックして、制限にひっかかれば破棄するようなプログラムを作り
常駐させることを考えています。

>>295
ローカルプロキシとは違うの？

やりたいことは似ていますが、プロキシを間に挟むことによる制限が都合よくないので
どちらかというとiptablesみたいなものが近いです。

例をあげろって言ってんだろボケ

>>297
プロキシを間に挟むことによる制限って例えばなに？

sctpって使ってる？　ふと気がつくと大抵のホストに実装がのっている感じ。　
ためしに簡単なechoサーバー／クライアントの組み合わせでソケットの生成を
socket(AF_INET, SOCK_STREAM,IPPROTO_SCTP)に変えただけでLinux上で
普通に動いた。

tcp上でメッセージの切れ目を探す手間が省けるかなというだけの軽い気持ち
なのだが、実際に使われているのか気になる。

>>297
http://www.linux.or.jp/JF/JFdocs/TransparentProxy.html

>>300
現状TCP/UDPでインフラが作られちゃってるから、
SCTPで動くものは非常にすくない。
使ってるのは大抵その人のオナニー。

ただ、遠い未来、SCTPに移行するのは間違いないと個人的には思ってて
色々勉強はしてる。

SCTPの特徴を三行で教えてくだしあ

http://www.ibm.com/developerworks/jp/linux/library/l-sctp/
http://ja.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
http://itpro.nikkeibp.co.jp/word/page/10006397/
http://www.asahi-net.or.jp/~aa4t-nngk/ipttut/output/sctpcharacteristics.html

ルーターは対応してるの？

>>305
第3層プロトコルだから通過する限りは別にIPだから必要なし。　ファイアーウォールや
帯域管理なんかはどうだろうね。　

とりあえずググるとIOSのスタック自体はSCTPに対応してるようだ
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ft_sctp2.html

>>302
> SCTPで動くものは非常にすくない。

今のところメジャー(?)なのはDiameterぐらいですかね。　しかしシステム内
通信ではかなり使われているんじゃないかと思います。　次のプロジェクトで
このミドルウェアを使おうかと思ってるんですけど
http://www.cs.wustl.edu/~schmidt/ACE.html

中にロッキード・マーティンによって書かれたSCTPソケットのサポートが
寄付されてました。

基礎的なところで相談させてください。
長文ですいません。

今勉強として、Winsockでチャットサーバーを作っています。

最初はWSAAsyncSelectを使い、WMで接続を受け付けたり、送られてきたデータを読んだりしていました。
・FD_READでデータを読み込み、バッファに貯める。バッファに発言内容が1つ以上貯まっていたら、それらを全ユーザーに送信し、不必要になった部分をバッファから削除する
といった感じで、うまく動いています。


その次に、以下の機能を追加しました。
「1ユーザーは5秒に1度以上は発言できず、それより短い間隔で発言がサーバーに届いた場合、遅延させて全ユーザーに届ける」
というものです。
「あ」「い」という2つの発言が1秒で届いたとしても、まずは「あ」だけ送り、「い」は5秒後に送る。という仕様です。
（何だその仕様。と思うかもしれませんが、「ユーザーの動作にたいし、遅延させてから情報を送る」実験のための仕様なので）

再現するために、WM_TIMERを1秒ごとにまわし、発言が「貯まっている」ユーザーを探して、貯まっていてかつ前回発言より5秒経っていたら送信するようにしてみました。

ここで気づいたのですが、このような「サーバーが一定時間毎に色々監視する」場合
わざわざWSAAsyncを使わずに、ノンブロッキングモードにして
acceptも各ユーザーのreadも1つのスレッドで回したほうが実装が楽そうだと思いました。

しかしながら
ttp://www.kt.rim.or.jp/~ksk/wskfaq-ja/
などでは「ポーリングは絶対するな」という風に書かれており、ノンブロッキングモードは非推奨のようです。

ではと、FD_ACCEPTやFD_READを使うとともに、別スレッドでユーザーたちを監視するような形にすると、今度はスレッド間の排他処理で実装が少し複雑になります。

「定期的に●●する」ようなサーバーを立てる場合、どんな方式でやるのが望ましいのでしょうか？

タイマー抜きでポーリングするとCPUパワーを食いつぶすからするなってことじゃない？
チャットならミリ秒で応答する必要もないので数百ミリ秒程度間隔をあけてポーリングすれば大丈夫だと思うけど

>>309
すいません、確かにポーリングが怒られているのは
「recvが、期待したデータ量をよこすまで延々ポーリング」
のような、それブロッキングでやれよといった内容についてのようです。

「サーバースレッド自体が永久ループ、その時非ブロッキングソケットを使うこと」について怒っているわけではないようですね。

どうにも非ブロッキングソケットはあまり良い顔をされていない気がするので、使う時「本当に使っていいのかな？」と迷ってしまいます。

非ブロッキングソケットは御法度だろ
WSAAsync使え

APIのほうで非推奨とかにされてないなら
あとはもう宗教だろｗ

動けばよい

非ブロッキングがご法度って、何で？
非ブロッキング＋select()って、ブロッキングの次にポータブルだから
何だかんだで良く使われてると思うけど

おれselectでグルグルしてるけど
今まで苦情言われたこと無いよ

サーバーのメインループでrecv処理なんてしたら、
誰かが高速で大量のデータ送ってきた際に、その処理に時間食われて
肝心のメインループが処理落ちしちまうだろ

recvは別スレッドでやるのが当たり前

>>316
効率上の話か
効率が再重要ならWSAAsyncSelect()も勿論ダメで
IOCP + Overlapped I/Oしかないんじゃね

>>317
極論すぎるんだよお前は

>>308
その遅延機能実装するなら、同じユーザの発言なら遅延するような
アダプタを出力前にかませればよいのであって。ソケットからどう
読むかなんてどうでも良いのでは？

>>318
いや、裏タスクは当然裏でやるとして
select, accept, recvを同一のスレッドで走らせると処理落ちすぎるぐらいの
サーバなんだろ？
IOCPしか無いと思うけど

CPUが100%から落ちなくてCPUクーラーがぶんまわってウゼエ
ってソフトがあった

WMPですね

要はWinSock(Windowsのソケット実装)がヘボいんだよ。
まあBSDモドキがMSの目的だったからな。
Windowsでまともなネットワークプログラミングをしたかったら、
モドキなWinSockじゃなくMS謹製のWindows APIを使えってことだ。

>>319が意味不明なんだが、誰か説明してくれ

>>308
下手の考え休むに似たり
case毎に適した方法でやるのがいい、一般的な解なんてない

>>316
まあいいんじゃないの？

>>323
WinSockでも、WinSock上でも無いNetwork APIって何？

>>327
こまかいな、意味分かるんだからいいだろ。
お前友達いないだろ？

>>328
プログラマって細かい性格じゃないとやっていけないと思うので、
これは職業病だと思って放置すれば良いと思いますよ。

いや、328はよくない
絶対に許さない

>>328
いや、俺も全く意味が分からないぞ

Winsock2使わず
> Windowsでまともなネットワークプログラミングをしたかったら、
って無理だろ

一体何が言いたいの？

>>328
「Windowsでまともなネットワークプログラミングが出来る
WinsockじゃないMS謹製のWindows API」について是非教えて頂きたい。
あなたは凄く詳しいようだから。

311=316=318=323=328
なのかなあ

winsockじゃないTCP/IPのAPIってあんの？
おせ〜て

nagleアルゴリズムについての質問です。
これを無効にした場合、順序性は保たれるのでしょうか？

たとえば以下のように再送の必要が出た場合、'B','A','C'とあべこべに届くのですか？
[クライアント]　　　　　　　　　　　　　　　　　　[サーバ]
'A'-------------->あぼん
'B'------------------------------->

<================================= NACK ('A')

'A'------------------------------->

<================================= ACK ('B')

'C'------------------------------->

<================================= ACK ('A')
<================================= ACK ('C')

>>335
順序とnagleとは関係ないだろう。

>>335
そのACK ('B')なんて出ないよ。
nagleアルゴリズム無効にしたからって順序性が崩れるわけがありません。
教科書読み直してガンバレ

>>336,337
ありがとうございます。
どうも覚え違いのようですね。
もう一度勉強し直してみます。

>>307
職業プログラマじゃないからよくわからんのだけど、
「システム内通信」って何？
あと、ACEはよく知らない(使ったことない。超重量級のライブラリだってことは知ってるw)
から、参考意見だせないなぁすまそ

>>339
「システム内通信」とはいわゆる、１つのシステムとして密に通信するプロセス間の通信。　
１ハードウェア上のプロセス間もあるし、複数のハードウェア間の通信もありうる。　普通はシンプルな
システム内だけで使われる独自メッセージングプロトコル。　

ドメインソケットによる通信とか、LAN内のRPCのことだとはわかるけど、
「システム内通信」は初耳だなぁ

いや普通にあるだろ。会社によって呼び方は違ったりすろけど。

会社によって呼び方は違ったりするなら、それは普通にあるとは言わないんじゃないか？

クローズド・システムにおける、
（しばしば独自のアプリケーション層プロトコルを使った）IPCってことか
昔なら電文とか言ってた奴だな

いやそういうものは確かに普通にあるけど
「システム内通信」なんて単語は、ぐぐっても、ズバリこれだってのが出てこねーぞ
閉じた世界でしか通じない隠語ならやめて欲しい

システムの中で閉じた通信 ってことで字面でわかるんじゃね？

そんなことより SCTP って表記が紛らわしいというか
STCPってつい書きたくなっちまうだろなんとかしろ！

まあ呼び名はどうあれ、主題(システム内通信? 独自プロトコル?)そのものは
誰も誤解していないと思われるから、細かい議論はいいんじゃねえか？

ところで、>>307に「しかし(SCTPは)システム内通信ではかなり使われて
いるんじゃないかと思います」とあるが、ホントなんだろうか。
>>340に「(システム内通信とは)シンプルなシステム内だけで使われる
独自メッセージングプロトコル」という定義があって、自分はそれに同意するんだが、
わざわざSCTPを使う目的が分からない。シンプルなメッセージングならTCPで無問題では？

>>346
データグラム型TCPという、聖なる矛盾に満ちた神プロトコルだからだろ。

電文がぶつぎりになったり後ろとくっついたりしないのは
ほんとにほんとうに便利だお

複数ルート使った冗長性も

通信伝聞って書いて誰も違和感を感じなかったｳﾁの社内。

「電文」って90年代後半から使われなくなった気がする
やっぱWindows95以降かな

>>350
マジか？
うちの仕事じゃ毎日のように使う用語なんだが遅れてるのかな・・・

会社次第じゃない

>>347
電文の切り出しなんかTCPでも電文長を頭に付ければ簡単に
出来るんだからSCTP使う理由になるわけない。

>>353
＞電文長を頭に付ければ
ﾌﾟｯ

>>353
電文長だけじゃダメだろ。
ヘッダ、電文長、本文、フッタ、サム
最低でもこんくらいいるだろ、齟齬無くやろうとしたら。

TCPなのに？

>>356
えっ？
データがおかしくなってもそのままおかしくなったまま被害が増大するのをほっとくの？

勝手に要件追加するなよ

>>357
ヘッダ、フッタにサム付きなんて、まるでベーシック手順全盛の時代を想い出すなぁ。
あぁ、そういやメッセージじゃなくて電文だったw

冗談はさておき、TCPだからサム(チェックサムのこと?)は不要。
もしやるなら、アプリケーション層で論理メッセージ全体のサムを計算させる。
たとえばファイル転送プロトコルなら、転送ファイル全体のサムだ。電文単位は無意味。

あれ、それともSCTPって信頼性の保証されないプロトコルなのかな。だとしたらUDP以下だ。

>>357
TCPならデータはおかしくならないよ。

IPは届いたデータがおかしくならない事を保証している。

>>356
ストリームだからだろ。

>>359
だから通信順序の保証されたUDPみたいな使い方が出来て便利だよ

>>362
どこまで話を戻したいんだよｗ
ストリームだと「なぜ」チェックサムが要るんだか言ってみろ

最低限ヘッダかフッタは必要だな

そういう意味じゃ改行ってフッタだな

まあ、もちついて、ここらでも読んでそれからだ

http://www.ibm.com/developerworks/jp/linux/library/l-sctp/

>>367
マルチストリーミングのところがよくわからん
解説してくんろ

>>353
簡単ではあるが、それがカーネル内でやってくれるというのは効率上大きな意味があると
思います。　切り分けが、カーネルと往復せずに処理されるという所に意味があると。

ちょっと質問
TCP通信で、途中のパケットが失われることってある？

A,B,C と送信してきて、Bが失われたとき、Cの受信時に
Bが失われたことを検知できるっけ？

>>370
入り口から入ったものと出口から出てきたものが同じであることを保障してくれるのがＴＣＰ

パケットが欠落したらＴＣＰの中の人が再送してくれるよ、ユーザーからは見えない

>>368
一つの接続の中に複数のストリームを流せると読んだ

>>368
>>370のときに、BとCが別ストリームだったらCだけ受信できる。
TCPだと1コネクション内に、TLV等でストリーム多重化しても、一つのパケットが落ちたら後続もブロックされる。
TCPで複数コネクション張れば同じだけど、今度は複数コネクションを一つのセッションとして扱う
めんどくささが生まれる。
1セッションに3ストリーム必要で、同時接続2セッションまで、みたいな制限かけるときとか。

こにちは。C#2010入れたみたけど、C#でのTCPｸﾗｲｱﾝﾄﾌﾟﾛｸﾞﾗﾑﾝｸﾞでお勧めはあるますか？
ttp://www.yoihon.com/sc/product-84512.html
この本はいかがでしょうか？感想お知らせください。ませ。

SCTPの利点は以下の通り。

マルチ・ホーミングのサポート。
コネクションのエンドポイントは複数のIPアドレスを持つことができ、ホストやネットワーク・カードの障害時にフェイルオーバーが可能。
別個のストリーム内のチャンクによるデータ転送。
これにより、TCPのバイトストリーム転送に見られるような、不必要なhead-of-the-lineブロッキング (待ち行列の先頭のデータがその後ろの転送を妨げること) を解消することができる。
経路選択とモニタリング。「プライマリ」データ転送経路を選択し、その転送経路の接続性をテストする。
検証と応答確認メカニズム。
フラッディング攻撃からの保護や、重複あるいは欠損したデータ・チャンクの通知を提供する。

>>371
つまり、Bが失われたときはCは来ないってことでおk？

>>376
Ｂの再送が失敗に終わればＣは来ない

>>377
ありがとう！

レイヤ７でいれるチェックサムはTCPでのチェックサムっていう意味じゃなくて、
（フレーム単位でのチェックサムではなく、）
セキュリティ的に改竄されてるかどうかとかそういうチェックサム。
（レイヤ７上でのプロトコルで改竄検出をするための）

>>379
セキュリティを語りたいのなら、「ハッシュ」とか「ダイジェスト」という単語を
選ばないと誤解されて当然だと思われ。「チェックサム」は誤り検出の文脈で使われる単語。
ところで IPSEC は知っているかな。レイヤ3(ネットワーク層)のプロトコルだけどね。

wininetのInternetOpenとInternetOpenUrlとInternetReadFileを使って、
yahooのページも何ページもダウンロードするプログラムを作ったのですが、
何ページ目かのInternetOpenUrlがerror code12152(ERROR_HTTP_INVALID_SERVER_RESPONSE)を返します。
yahooが連続アクセスを拒否したという事なのでしょうか？

>>381
そういうことです

【社会】 図書館ＨＰにアクセス３万３千回で、会社社長逮捕。１秒に１回アクセス繰り返すプログラム作る…愛知
http://tsushima.2ch.net/test/read.cgi/newsplus/1274928007/

21回も鯖落としても給料に反映無しってのがお役人さね。
Windows Server 2003 Microsoft-IIS/6.0 26-May-2010 202.238.45.27 Okazaki City Library
IIS6で5ｸﾗｲｱﾝﾄ超えただけとかいうｵﾁなら笑いもの

>>382
やはりそうですか・・・。

>>383
タイムリーにこんな事件が起きていたのですね。
しかし、1秒に1回というペースでも問題になってしまうとは。
ロボット型サーチエンジンなんかはどうしているんだろう・・・。

図書館の検索なんかは GET リクエストじゃなくて POST リクエストだから、
普通のロボットは retrieve しない。

鯖を落としたとは書いてないんだけどな。

閲覧しにくい状態が続いた。
21回停止されていた。

サーバへの攻撃と判断して、一時的にhttpdを停止させたのかも知れない。
サーバ保護のための措置（緊急回避）なんだから、管理者が責任を問われることはないだろ。

1tpsで重くなるって弱っちすぎる。
地方自治体の図書館なんてどこもヘボが作ってるんだろうな。

動機は、しばらくアクセスしにくい状態にしておいて、「うちで開発しましょう、
快適になりますよ」とか売り込むつもりだったんじゃないかな。

オレの地元の図書館もヘボっちすぎて作り直してやりたいと常々思ってるから、
理解できる。

たしてちょうど15になる7個の自然数の組合せをすべて列挙するとともに、
すべての組合せを表示し終えたら、それらの組合せが全部でいくつあるの
かも出力するプログラムを作成しなさい。

#include<stdio.h>

int main(void)
{
int i,num;

printf("自然数の組合せ\n");

num=0;

for(i=1;num<=14;i++){
num=num+i;
printf("%d\t",i);

}

printf("組み合わせは%d通り\n",num);

return 0;
}

現在ここまで作りましたが、プログラムがわかりません。
誰か教えてください。

言語はC++
環境はVisual です。

数十文字のスレタイも読めなんだから入門書なんて読みもしないんだろうな

>>391
すいません。間違えました。

>>388
うちもだよ
蔵書検索に30秒くらいかかる

>>381なんですが
ttp://quoterank.yahoo.co.jp/ranking/search?b=1&kd=31&mk=11%2c%2012%2c%2021%2c%2022%2c%2031%2c%2032%2c%2043%2c%2047%2c%2083%2c%2087%2c%2094%2c%2097%2c%2017%2c%20A1%2c%20A7%2c%2037%2c%2019%2c%2029%2c%2039%2c%2049%2c%2089%2c%2099%2c%20A9&ca=1&tm=day&
このページは何回ダウンロードしてもエラーはでないのに、
ttp://table.yahoo.co.jp/t?s=8031.t&a=3&b=3&c=2010&d=6&e=4&f=2010&g=d&k=20100528
このページは数回ダウンロードするとエラーが出ます。
1DL毎に10秒時間をあけてもだめでした。

どういうアクセスを拒否するかは、yahooのシステム次第だと思いますが、
一般的にアクセスを拒否する仕組みはどのような物があるのでしょうか？
なんとかしてプログラムでダウンロードしたいです。

>>394
エラーの詳細は？

>>395
>>381の3行目に書いた事しか分からないです。

専用ブラウザの書き込み通信をモニターして、書き込みがあった場合
次の書き込み可能な時間が来るまでのカウントダウン表示をする
アプリを作りたいのですがどのようにすればいいのでしょうか？

>>396
バケットキャプチャは？

>>398
Wiresharkで見てみたんですけど、データの見方がわからないです。
通信は難しいなぁ・・・。

>>399
なんかコードがバグってる気がするな
10秒間隔でWebブラウザで開く分には問題よね？

総務省が日本のISPを巻き込んで検閲するって本当なの？
それもパケットキャプチャレベルじゃなくてISPでキャプチャするユーザパケットレベルで検閲する（広告利用とか言ってるけど実際は検閲のこと）ってので、
現在中国やグーグルがやってる検閲以上のを検証してるようだけど。

ゆくゆくは総務省が財務省や外務省の通信内容を全部検閲しようって腹積もりだよ。

既に中国やアメリカからハッキングされて筒抜けなのに、さらに国策レベルで自分の首をしめるようなものだよな。

なんの話？児童ポルノ対策の話？

>404
http://headlines.yahoo.co.jp/hl?a=20100605-00000003-jct-sci

>>400
ブラウザで更新ボタンを何回も押すのは問題なくできます。
再度、コードをチェックしてみます。

>>405
こういうのって、昔から過剰に反応する人がいるんだよな
昔はパソコンに疎いおっさんが、中の動作を知ったときにわめくことが多かったけど

>>403 みたいな病人もいるしな

一般人には専門的なことはわからんよ。
重要なのは恐怖だ。

いや、違反者への罰則は外患誘致みたいに死刑のみにしないと、
クズがデータを転売するに決まっている。

WindowsでTCP/IPサービスが利用できるかチェックするいい方法はありますでしょうか？
たとえば、LANならロカールエリア接続が有効になっていて、TCP/IPプロトコルが有効になっていて、
とかそういうのをひっくるめて。しかもすごい頻繁にチェックするのですが。

>>411です。
ああ、頻繁じゃなくてもいいです。タイマーか何かで定期的にチェックして
その結果でフラグセットしますので。

>>405
ネット情報すべて解析する技術　利用者から「使用やめろ」の大合唱
6月5日18時12分配信 J-CASTニュース

だが通信の秘密は、通信当事者の同意があれば侵害とはならない、とも書かれていた。こうなると、同意があればDPI技術を利用してよいと読み取れなくもない。
総務省はDPIによる行動ターゲティング広告を容認したのだろうか。
総務省消費者行政課に取材すると、「そのような事実はありません」と明確に否定した。

　同課によると、そもそも「提言」は、DPIの課題を研究会で検討した内容を整理したものに過ぎず、この段階で「容認した」という類のものではない。それを踏まえたうえで、「同意」の内容について大変厳しい解釈を示していると主張する。
例えばサイト上での周知だけ、契約約款に規定を設けるだけでは「同意あり」とはみなさないという。
一方で、ISPと新規契約する際の契約書に、「行動ターゲティング広告への利用を目的として、DPI技術を使って通信情報を取得することに同意する」という欄を設けた場合は、
「個別かつ明確な同意」として認められるという。仮に同意した後でも、「やはりDPIの使用はやめてほしい」となれば簡単に中止を求められる「オプトアウト」の機会を提供するよう、ISPに求めるとしている。
これらは、「一部の法学者から『厳しすぎる』との声があったほど」（消費者行政課）高いハードルだという。

リアルだと警察が街中に監視カメラ設置して、個人商店には警察協力と称して設置を強要してやりたい放題でしょ。
警察がやりたい放題になっている社会の方が問題だと思うよ。
イスラエルとかジャマイカとかだと警察官が気に食わない奴の家に上がりこんでそいつを当たり前の表情で殺してる。
日本だと警官が人殺しをすることは無いけど、警察利権を作るだろうね。たとえば交通道路とか風俗・警備会社許認可権、最近だと監視カメラ利権でしょ？
銃刀法も扱ってるから、例えばなんでもないプラモデル屋やフィギア屋にすら「ナイフだろ！」とか言いがかりつけて、気に食わなければ逮捕とかも可能だろうね。
警察が幅を利かせるようになると国家の監視どころじゃなく警察に統治されるようなそういう世界がまっている。
ネットよりリアルの方が窮屈で監視社会（全体主義的な検閲社会）になってるなって感じはする。

>>411
netsh

>>411
acceptして放置

ネットワークを扱った書籍で、子供だましな誰得？なｻﾝﾌﾟﾙｱﾌﾟﾘとか
やってはいけない馬鹿の見本なｻﾝﾌﾟﾙｺｰﾄﾞとかじゃなく
まじめにきちんと設計されたアプリを書き上げた書籍ってありますか？

>>417
UNIXネットワークプログラミング<Vol.1>
がもっとも要求に近い。

>>417
なんでオープンソースのコードを読まないの？

TCPDUMPについて質問させてください

tcpdumpからソースIPとあて先IPをスプリクトで抜き出し
エントロピー値を取ろうと思うのですが

スプリクトは直接TCPDUMPは読み込めないので
tcpdumpをｔｘｔファイルに変換させることは可能でしょうか？

Wiresharkで読み込ませて、txtにしようと思ったのですが
うまく行きません

レベルの低い質問ですが
どうかご教授お願いします

>>418,419
半角カタカナという基本的なネットのリテラシも無い、やってはいけない馬鹿の見本のような
カキコを平気でする>>417みたいなのに何を言っても無駄なだけ。
>>418の挙げた書籍には大いに同意するし自分にはバイブルだったけど>>417には豚に真珠。
>>419が何を言っても馬の耳に念仏だお。

近所にﾐﾆﾌﾞﾀ飼ってて奥さんが颯爽と散歩兼ねてｼﾞｮｷﾞﾝｸﾞしてる。
真珠かｲﾐﾃｰｼｮﾝか知らんが結構似合うﾓﾝだぜ？豚に真珠。

で、>>417には似合うのか？

>>420
IPってゆうな。クズ。

>>420

スクリプトから直接読み込みたけりゃリダイレクトして標準入力から読めばよろし

ファイル経由でよいならtcpdumpの出力をファイルに落とすオプションがあったと思うぞ

そういえば、「バイト数の節約になるんだ」とかいって
EUCやUTF8でも半角かなを使っている人がいたな。
今でも元気にしてるかな・・・

そういう奴ほど元気で長生きなものだ

半角ｶﾅ駄目とかいう暴論者は10年ほど前に絶滅したと思ったらまだいたんだな…

半角かなの特性を正しく理解せずに使っているのが癇に障るんだろう

今時7ﾋﾞｯﾄしか受け付けないﾒｰﾙｻｰﾊﾞなんてあるんですか？

悪魔の証明は不可能だよ

そういえば外人って°とか℃とか�uとかどうやって入力してるんだろう？

degreeとかdegree celsiusとかsquare meterとか書いちゃうよｗ

>>421のせいで基本的なネットのリテラシも無い、やってはいけない馬鹿の見本のような
カキコを平気でする奴が出てきた。もう何を言っても馬の耳に念仏だお。

>>420
tcpdump > tcpdump.txt

結局半角カナを使う馬鹿って生き残っちゃったよな

>>436
(ﾟ∀ﾟ)これも半角だしNE!

文字コードとして割り当てがあるのに使ってはいけないとか言う子の意図がわからんな

>>438
8bit->7bit変換のときに単純に8bit目を落とす馬鹿鯖があるからだろ

ISO-2022-JPでは使わないことになってるエスケープなのに、使っていいとか思ってる子の意図がわからんな

>>440
ISO-2022-JP以外なら使ってもいいってことだから問題ないよ。
ISO-2022-JPに変換しなければおｋ

バカっぽく見えるから使わない方がいいよ。逆にバカっぽさを強調したい場合には使うのもあり。

こいつらの作るアプリはさぞ使いにくいだろうなｗ

黙れ
ﾈﾄｳﾖ

>>444
極めて正しい用法。

>>442
ｲｯﾃﾖﾁ!

>>442
半角かなを使わないに越したことは無いが
半角かなを受け入れられないソフトは糞だ。

半角ｶﾅ駄目とか30年前からタイムスリップしてきたのか？ｗ

半角カナ使う奴の方が30年前からタイムスリップして来てるのだが

両方使えるようにすればいいだけじゃん。
エンドユーザーなんて何するかわからん。

�梢ﾚ？

>>440
つまり�@�A……も禁止か？"−"もだめそうだが？

潔く捨てるのがルータの教え。
利用者に使えないんだと理解させるためにicmpで通知してあげればいい。

icmpてピングでしょ？どうやって通知するの？

昔はメールを書く時には半角カタカナや機種依存文字を使うなとしつこく言われたものけど、
最近は初体験で日常的なメールというのがケータイであるという奴が増えているから、
半角カタカナや絵文字について何も違和感を持たず、同じ感覚で2chにカキコしてるんだろね。
で、社会人になってから、常識の無い奴とドヤされるわけだ。

昭和時代はカタカナでメールを打つのが常識だったんですか？

ポケベルで数字打つってのが常識でした。

53 93 65 05

実に滑稽ｗ
そのうち時代後れな事を言ってる奴が”文字化けするから「表」「予」「申」「能」「十」「ソ」なんかの文字も使うな！”とか言いだしそうだぜｗ

\表

森鴎外叱る

>>459
俺鬱
JIS-X2010

>>459 半角カナを使うような無神経な奴ほど、トラブルに対してそういう対応をするけどな。俺の経験上。

エスケープするなら表\だろ。

>>463
おまえの負け

検索で半角カナと全角カナを厳密に区別するソフトとかあるからなー
必要に迫られない限り、使わないにこしたことないでしょ。機種依存文字なんだし

バカっぽい雰囲気を出したいときは必須。

一般の人の反応：　昔は使えなかったとかごちゃごちゃ言ってるけど、
今は使えてるんだからい〜じゃん、あほくさ

>>420
Wireshark(Ethereal)に付いているコマンドラインツールのどれかに、
そういう機能があったと思う。

Wireshark Manual Pages
ttp://www.wireshark.org/docs/man-pages/

ﾌﾟｹﾞﾗ

初歩的な質問
UDPのパケットがフラグメントとかされて途中で分断されてても
アプリケーション層でrecvfrom成功した時は送信されたパケットと同じサイズの
データの取得は保証されてる？

UDPはパケットの到着順は保証されないけど、パケット単位での再結合が成功済みの
パケットしかアプリケーション層までは到達しないんだよね・・・？

眠いのかい？

>>471
到達しない。

というか、フラグメンテーションはIP層で行われているからUDPは
完全なIPパケットしかもともと受け取らない。

>>473
thx

さらにもう一個質問。

PC Aが100byteのUDPパケットをPC C Port1234に送信
PC Bが100byteのUDPパケットをPC C Port1234に送信

PC CがPort1234からrecvfromで50byteずつ取得、ってケースだと
Aの最初50>Bの最初50>Aの最後50>Bの最後50
とかの順番で取得されるケースもありえる？
ありえるならUDPの受信ってテンポラリバッファ＋送信元IP/Port毎の独立バッファ
で受信しないといけなくて凄く実装が面倒なんだけど・・・

>>474
ない。
もしどっかでちょん切れたら最後の50はうしなわえう

＞もしどっかでちょん切れたら最後の50はうしなわえう
ちょっと待て。
「最後の50」だけ失われるケースはありえないだろ。

ちょん切れて飛んできても勝手に結合してくれるし、もし結合できなかったら「最初の50すら捨てる」だろ。
そうじゃなきゃUDP使えないってのｗ

データ部が548バイトまでなら絶対分割されないから、分割が心配ならそのサイズまででやればいい。
548バイト超えると分割されたり、再送がどうだの発生したりで性能劣化していくし

あってるよね？

IPヘッダ内に「分割(フラグメント)可否フラグ」というのが存在している。
サブネット間に位置するルータは、パケット転送時に分割が必要な場合、
このフラグを参照し、もし不可であれば単純にそのパケットを破棄する。
で、一般的なUDP実装では、このフラグは「常に」不可に設定される。
だから(>>474のような)ネットワーク上を分割されたUDPデータグラムが
流れる現象そのものが起こりえない。

ただし、このフラグを許可に設定するような「行儀の悪い」UDP実装が
送信者であった場合、どうなるかは知らない(予測できない)。
分割されたUDPデータグラムを単純に破棄する受信者が大半であると思われる。

>>476
分割するハメになったら破棄されるんだから、結合はないよね？
もしかしてあるの？

パケットロスや順番入れ替えが無かったと仮定して。
sendtoで"A""B"..."Z"と一文字ずつ26回送った場合
受信側はrecvfrom一回で"ABC..."とかくっついて受信されずに
recvfromを26回、一回につき一文字ずつ受信できるのは保証されてるのかな？

TCPだとrecvの戻りはいくつかのパケットがくっついたりパケットの途中で戻ってくるけど
UDPではsendto/recvfromは1:1対応してる、と想定して作っていいんだよね？

そもそも、そんなことを気にしなきゃならないような通信を
UDPで実装しようって設計が間違ってる気がする

>>480
それが書いていない教科書はクソだし、検索すればいくらでも出てくる。

>>480
作るときはパケットの区切りは、どこか分からないものとして作るんだよ
ここが区切りですなんて情報はくっついて来ないから


入り口から入れたものが同じ順番で出口からでてくるのがTCP
順番が狂ったり出て来ないのがあるのがUDP
そんだけ

>>483
> 作るときはパケットの区切りは、どこか分からないものとして作るんだよ
それはTCPだけ。　UDPはおk。

>>482
とりあえず１冊入門書読んだんだけど見つからなかったんだ・・・
UDPのRFC読んだけどそう動作するよう実装するべし、みたいなのが見つからなくって
ネットで探した限りSUNのページにそれらしい記述があったけどSUNの実装が
そうなってるだけでBSDソケットと名乗るなら必ずそう動作する、って保証はあるのかなぁ、と

>ただし、このフラグを許可に設定するような「行儀の悪い」UDP実装が
みたいにソケット実装者の気分次第でどう動作するように実装してもよくて
たまたま多くの実装がそうなってるだけとかだと嫌だなぁと

>>485

スタックを使う側はそういうのは考えなくてよろしいのよ

スタック自体を実装するのなら、思いっきり考えてくださいまし

自分とこで使ってるスタックの実装に合わないパケットはスタックが捨ててくれるんだから
よそ様が何をつかってても関係ないでしょ

>>485
UNIXネットワークプログラミング<Vol.1>
を買ってこい。今すぐ！ダッシュでだ！

>>486
UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、
で使う側の実装はまったく違うものになると思うが・・・

で、二種類の異なるハード・ＯＳ（両方BSDソケットは使えると言ってる。ちなみにWinでもLinuxでも無い。CPUもIntelじゃない。）
がNAT下にあってUPnP/STANでNATのUDPの穴あけは相互にできるけどTCPは保証できない、
という環境でUDP使ってP2Pで通信してね、というお仕事を引き継いだんだけど
UDP使うの初めてで色々わからんのよ・・・

>>488
>UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、

それ以前に到達することすら保障されてないわけだが、そこはいいの？

良く分からない仕様で悩んでるよりも
出てきたデータをストリームとして扱えば、1対1だろうが多対１だろうが問題ないんじゃね？

>それ以前に到達することすら保障されてないわけだが、そこはいいの？
UDP使うしか無い以上その保証はアプリ側で対処するしか無いです。車輪の最発明は嫌だけど・・・

>出てきたデータをストリームとして扱えば、1対1だろうが多対１だろうが問題ないんじゃね？
順番が保証されないデータのストリーム前提の実装って、無理じゃないけどえらい面倒＋メモリ＆ＣＰＵ資源の
無駄が多そう。あんまり富豪的なプログラムできるほどリッチなハードでも無いし。

BSDソケット使えると言ってるならアプリケーション層までたどり着いた
UDPパケットは1:1保証されてるんだよ、となればその前提で組めるので
助かるなぁ、と・・・

>>488
期待しなきゃだめだろ
その代わり順番も入れ替わるし無くなることもあるというだけの話

>>491
だよね

前任者のコードで
struct hoge {
int tag;
int size;
char data[0];
};
char buf[512];
int size = recvfrom(buf,sizeof(buf),ip,port);
if (size >= sizeof(hoge) && ntohl(((hoge*)buf)->tag) == TAG && ntohl(((hoge*)buf)->size) == size) {
//受信処理
}
みたいなコードがあって
TCPではこの作りダメだけどUDPならいいのかな？と疑問だったけど
UDPのsendto/recvfromは1:1対応を期待できるなら大丈夫だね。

>>492
rfc1180
UDP preserves the message boundary defined by the application. It
never joins two application messages together, or divides a single
application message into parts.

後、キミはBSDソケットの位置づけを誤解している。

>>478
> で、一般的なUDP実装では、このフラグは「常に」不可に設定される。
いつからそうなった?

少なくとも, 4.2 BSD の実装時点ではそうできてないし,
unix 系の実装でそうなっているやつは見かけないんだが...

で, 今, 手元にある FreeBSD あたりだと
% sysctl net.inet.udp.maxdgram
net.inet.udp.maxdgram: 9216
てなことになってるが

>>493
RFC1180にあったのか。これってTCPだけじゃなくUDPについても書いてあったんだね。
UDPだからRFC768を見てた。さんくす

>後、キミはBSDソケットの位置づけを誤解している。
SDKのドキュメントに"BSDソケット準拠のソケットライブラリ"と書かれていたから
"ANCI準拠"とかと同じ統一規格の一種かと思ってたんだど、誤解かな？

>>495
BSDソケットはAPI, プロトコルではない。

> BSDソケットと名乗るなら必ずそう動作する、って保証はあるのかなぁ、と
という表現はおかしい。

> BSDソケットはAPI, プロトコルではない。
「Berkeley 互換を名乗るなら動作を含めて互換にしてほしい」ってのはわがまま?
組み込み用途のスタックとか Berkeley 互換をうたいながら全然互換じゃない実装って結構あるのな
まぁ, メモリに余裕があれば移植してしまえば済む話ではあるが...

> 「Berkeley 互換を名乗るなら動作を含めて互換にしてほしい」ってのはわがまま?
やっぱりAPIだと言う事を理解していない
APIだから、socket(PF_INET,...)がEPROTONOSUPPORTを返したってBSDソケットの正しい実装。

APIって、セマンティック含めてAPIだろ。
名前が同じならいいってもんじゃない。

BSDソケットは、特定のプロトコルの実装を要求していない。

>>498
API ってのは, 仕様があってはじめて API って名乗れるもんではないのか?
Berkeley の仕様なんてどこにもないんだが…

# 強いて言えば, posix の要求仕様程度かな？

初期の Postscript 互換言語なんて bug も含めて互換性を求められてたぞ
xterm に至っては忠実に vt100 の bug まで再現してた

下らない言いがかりをつけるのはキミの自由だけど、世の中の大部分の人はAPIだと考えている。
http://en.wikipedia.org/wiki/Berkeley_sockets

どうしてもBSDソケットはAPIじゃ無いと言いたいなら、理由を列挙して署名入り記事でも発表しなよ。

>>501
manすら見たことない事を全力で告白しなくても良いぞ。

Windows でネットワークプログラミングを始めました。
Linux ではちょっとやっていたことがあります。

マルチスレッドで処理をしようと考えているのですが、Winsock のいくつかの関数がスレッドセーフなのかどうかがよくわかりません。
1つのスレッドで 1つの socket を扱っており、例えば recv の後で WSAGetLastError を呼び出しているのですが、
WSAGetLastError はスレッドセーフなのでしょうか。
スレッドセーフではない場合、どう対処するものなのでしょうか。

gethostbynameなどはスレッドセーフじゃないという情報があったので、mutex を使って排他しています。
しかしながら recv から WSAGetLastError までを排他すると、マルチスレッドのメリットが無くなってしまうんじゃないかと思う次第です
（この socket はブロックモードです）。

>WSAGetLastError はスレッドセーフなのでしょうか。

いいえ

>スレッドセーフではない場合、どう対処するものなのでしょうか。

WSAGetLastError を使わない

http://msdn.microsoft.com/en-us/library/ms741580%28VS.85%29.aspx

The return value indicates the error code for this thread's last Windows Sockets operation that failed.

英語はあんまり得意じゃないんで読み間違ってたらすみませんが、
>>506
>The return value indicates the error code for this thread's last Windows Sockets operation that failed.

for this thread's とあるので、「*このスレッド*で起きた最後の失敗理由を返す」って意味で合ってますか？
であればスレッドセーフってことなんじゃないかと思うのですが、どうなんでしょう？ >>505

ただのアホの戯言ですよ

>>502 すまんな、急な出張が入ってた
それは *nix とか, Windos とかの資源が潤沢なところの世界の話だ

>>504
1つのスレッドで 1つのsocketを扱っているならWSAGetLastErrorを
複数スレッドで同時に呼んでも全く問題なし。

1つのスレッドでWSAGetLastErrorを*同時に*呼ぶ事はできないから
WSAGetLastErrorの使用に関して条件を付ける必要は無い。

>>510
アホはいい加減黙れ

メールのプロトコル（SMTP/POP3）に関して勉強したいのですが、お勧めの書籍などありますでしょうか？

とりあえずAmazonで
http://www.amazon.co.jp/dp/4873110289
http://www.amazon.co.jp/dp/479810941X
の二冊を見つけましたが、お読みになっている方のインプレ、または他にお心当たりがありましたら是非ご教授ください

※ライブラリやアプリケーションの使い方の質問ではない、ということでこのスレで質問させていただきました。
　他に適切なスレがありましたら誘導していただければ幸いです

SMTP と POP3 だけなら　RFC（の日本語訳）サイト　で十分じゃね？

ちょｗｗ誰がうまい事をいえと言ったｗ
http://stream.everywebhost.com/hitec/sport/j7.html

これ見てよ↓
http://livedoor.blogimg.jp/tekepo/imgs/3/4/3414dfca.jpg
ばらまこうぜ！

>>516
自分で拡散してお前がアク禁食らえ。カス。

>>514
いや、まぁ、確かに最後に見るのはソコなんでしょうが・・・。
出来ればもう少しナンパな本は無いでしょうか？（苦笑

最後じゃねえよ最初に見ろドアホ

>>518
＞　※ライブラリやアプリケーションの使い方の質問ではない
ということから、少なくともソケット操作はできる前提
→　なら SMTP POP3 のプロトコルの話
→　結局 RFC が全て
こういうことだ。　で、その部分だけを書籍化するのは…　…（とても少ないという意で）厳しいか？

メールのペイロードの部分(ヘッダとBODY）で、MIME関連まで網羅しだすと
一気に大爆発するがね。

優秀ｗな人材ｗが束になって時間ｗと金ｗをかけて作ったメーラーが
十年単位でバグだらけだった事実

OE

メーラーでトラブルのは文字のｴﾝｺｰﾄﾞ/ﾃﾞｺｰﾄﾞ周辺じゃねーの？
SMTP で送る/POP3 で受ける　部分はそんなに複雑じゃないと思われ

なるほど、申し訳ありませんでした。
メールに関しては、RFC＜MIMEや文字エンコード、なのですね。
では改めて、そのあたりも含めて、（大爆発しない程度に（汗））解説している書籍などはありますでしょうか？
とりあえず>>513は二冊とも通販で注文を出しました。

>>520
はい、その前提でOKです。
直接、ポート25や110を叩きます。

人の話をきけよ！

>>524
RFCに全部書いてあるし変な本より読みやすいから
直接読むのをおすすめする

書籍は結構省略されていて結果的に使い物にならない
分かった気になりたいだけならおすすめ

なんつーか
"RFC読める俺かっこいい"とか
"俺はRFCを読んで苦労してるんだおまえも苦労しろ"
みたいな意味を含んだレスって読んでて痛いよなぁ
こう言う事言う人って生産性のない学生に多いのよね…

そんな人はいないように見えるんだが、君はそんな風に感じたのかい？

世の中には辞書が読みやすいという変態がいる
だからrfcが読みやすいとかいう変態がいても不思議ではない

rfcは辞書じゃないし

>>527
RFCが何だかわかって言っているの？

生産性のある社会人はRFCを読まずに俺様解釈とコピペで仕事するので、
クズ実装を非常に高い生産性で排出するわけですね、わかります。

>>527
三流底辺技術者の言いそうな台詞だなｗ

>>532
マイクロソフトの悪口はそこまでだ

初歩的な質問ですみません
connect/acceptでクライアントとサーバが接続状態であるなか
どちらかがclosesocketしたら、recvが失敗して初めて切断されたと分かるんですか？

>>535
同期ソケットなら普通はrecvの前にselectして検知するな

>>536
えらいなー。俺面倒だから切断処理は全部recvでやっちゃうわ。
つーか通常切断されるとselectは正常に抜けてきちゃうから
readとかで0バイト受信かどうかを見るのが一番ラクダと思う

WindowsXPとUPnP対応のルータで、NAT超えの簡単な通信プログラムの
サンプルはないでしょうか？

また、ネットワークを一つのPC内で擬似環境を
作ったりするツールとかないのでしょうか・・？

>>538
vmware

>>538
http://miniupnp.free.fr/

>>538
VC++でよければ晒すが

socketを使ったプログラミングって、受信と送信の両方をプログラミングしないとダメなんですか？

一方通行のプロトコルならば片方でOK。

>>543
thx

>>543
ミサカネットワークに接続するんですね

誘導されたんで転載
ネット対戦ゲーム作ろうと思ってるんだけどさ
プロトコルがUDPでUDPの特徴としてコネクションレスであることが挙げられると思うけど、
それってつまりクライアント側の「準備完了」メッセージをうっかり取りこぼしたら永遠に準備完了にならないってこと？
サーバーから「受け取りました」メッセージ届くまで送り続けないといけないの？

うんそうだよ
自分でプロトコルを実装しないといけない。

>>546
たいした量じゃないなら毎回「状態」を送るのも手だな。
エッジトリガじゃなくてレベルトリガで動作するようにする、と。

>>546
そういうのはゲームが開始されるまではＴＣＰで面倒見るのが楽。
１：１なら開始するまでリトライすればいいから楽だが、
１：他になったときにＵＤＰだけだとスゲー面倒だよ。
参加者のうち一人がサーバーになって、皆でＴＣＰでサーバーに接続して
ゲーム開始情報とかはサーバーから一貫した情報送るとかいう仕様にすれ。

よくよく考えたら全部TCPでよかったわ
ありがとう

writeとかsendが嫌いなんでfdopenでfprintfとかで使えるようにしたんだけど、
どうもうまく動作しない。
一番最後のfprintfで引っかかり、さらに最初のfgetsが動かない。
fgetsはまぁサーバー側のfprintfでみすってるからだろうけど。
下にその部分のクライアント側のソース貼っとく、おかしなところ頼む。
ちなみにここまでは全部問題ない。
あ、変数はfpがFILE*型でstrはchar型の配列、sockはWINSOCK型。
途中のDelRet関数は文字列中の\nを消すだけ。

fp = _fdopen(sock, "r+");
if (fp==NULL) {
__printf("fdopen() Failed.");
__exit(1);
__}
setvbuf(fp, NULL, _IONBF, 0);

__if (fgets(str, sizeof(str), fp)==NULL) printf("NULL1\n");
__if (fprintf(stdout, "%s\n", str)<0) printf("fprintf()1\n");
__if (fgets(str, sizeof(str), stdin)==NULL) printf("NULL2\n");
__DelRet(str);
__if (fprintf(fp, "%s\0", str)<0) printf("fprintf()2\n");

そうですか。

>>551
winsock fgets でぐぐる

_open_osfhandleがキモだけど、
自分ならこんなキモい命令使わされるくらいならsend/read使う

>>553
そうしようかな。。。
というかずっと疑問でrecvを使わなかったんけど、recv()の引数の受信サイズってどうやって知るの？
文字列なんて長さが一様なはずがないからどうにかして文字列長を取得しなくちゃいけないと思うんだけど。
先に受信サイズだけ送っておくとか？
256とかって設定しちゃったらそれ以上のデータを送りたいときどうするの？
という疑問がずっと解消されてないんで、誰か解説お願い。

いくらなんでも基本中の基本すぎて、釣りにしか見えん。
でも釣りじゃなかったら可哀そうだから答えるけど

send１回で送ったデータが、recv１回でとれるとは決まっていない。
なので文字列長とかは自前で受信側に通知する。

・文字列長を最初に送ってから、実際の文字列を送る
・'\0'を受け取るまで受信側がrecvを繰り返す
のどちらかが一般的だな。

>>555
'\n' を受け取るまで受信側が recvを繰り返す (fgets を意識した感じ
recv の受信ﾊﾞｲﾄ数が 0 になるまで繰り返す　（＝切断されるまで読みっぱー）
もありそうな話やね

釣りじゃないッすorz
ほんと可哀そうなやつで申し訳ない
んで丁寧に教えてくれてほんとにありがとう

俺は>>551の１行目で釣りとわかったぜ

おまいら叩き過ぎだろ。できの悪い本なら
Ｓｅｎｄ１回につきＲｅｃｖ１回で取れる保障がないこと自体書いてないぞ
ネコわかとかな。

できの悪い本の話なんてどうでもいいんだが？

できの悪い本手に取ったならそういう質問がでてもおかしくないって話してるんだが。
まー最初からWinsock Programmer's FAQあたり読んだほうがマシだな。

そんな話してないよ？

2chもレベル落ちたな

>>553でrecvをreadって書いちゃったはずかひい

そういやスレッド間通信にUDP使うクソ害虫がいた。
内部通信だから大丈夫です（ｷﾘｯ)って言ってたけど、
案の定負荷かけたらボロボロ落ちまくりわろた

CMSを自作したいんですが
javaサーブレットとPHP どっちがいいですか
データベースはたぶん使いませんん
Webアプリケーションとの連携がしたいです

なんで設計をすっ飛ばして製造に入ろうとするんだろうな

早漏でござる早漏

P2PのDHTを作ってるのだけれども
UDPで実装なんだけども
UDPはパケットサイズ512以下じゃないと届かないことがあるとか言いますが
未だにそんなごみルーターがごろごろしてるの？
今時サイズなんて気にしなくてもたいして支障はないのかな？

サイズが小さくても届かないときは届かない

>>569
そんなことは分かってる
DHTは最初からそれを考慮して設計されてるから問題ない
聞いてるのは最近のルーター事情において
512と1024では届く確率に差が出るのかということ

pgr

>>570
1500超えなきゃまず大丈夫じゃね？
1500超えてもIPパケット分割されっし結構いけるんじゃね？

log2n2の確立で差異が出るが、ルーター事情によるものではない。
送信間隔はどのくらいのしてる？
１０ｍｓ以下のインターバルで送信しまくったりしてないよね？

MTUの設定値が低い場合は差異がでるかもしれんね

>>572-574
なるほど、その言葉を信じてとりあえずやってみる

tracerouteでテストしてみると、tracerouteの許す最大32768バイトあっても結構通るな。

$ traceroute www.google.com 32768
traceroute to www.l.google.com (173.194.33.104), 64 hops max, 32768 byte packets
1 gateway (192.168.0.1) 49.395 ms 35.878 ms 21.430 ms
...
10 GOOGLE-INC.edge3.NewYork2.Level3.net (4.59.128.18) 66.696 ms 59.012 ms 157.592 ms
11 216.239.43.114 (216.239.43.114) 160.010 ms 207.188 ms 84.967 ms
12 216.239.48.24 (216.239.48.24) 145.018 ms 151.946 ms 135.050 ms
13 173.194.33.104 (173.194.33.104) 144.856 ms 67.043 ms 172.199 ms
　

ルーター事情ならだめなものはだめ、いけるものはいけるで
確立云々ではないだろう
確立的に届いたりとどかなかったりするのは、回線事情のほうでしょ

>>577
P2Pって書いてる通り特定の経路を前提にしてないから
古いルーターにぶち当たる確率です

>>578

古いからじゃなくてファームのバグじゃないの？
あるいはファイヤーウォールの設定？
回線業者がそれを放置したら苦情殺到だからまずありえない

エンドユーザーのルーターならそれを使いたいやつは
ファームの更新するか買い換えるだろうから気にしなくていいんじゃね？

企業内のネットワーク事情？、ゴッドノウズｗ

>>579
そういうのに当たる確率の話でしょ

>>579
古いというかバグというか、それ以前のルータが氾濫してるんだ。

フラグメントされたパケットはTCP/UDPのポート指定されたフィルタには
適用されませんだとか、フラグメントされたパケットはNATに対応してませんだとか、
そもそも仕様さえ無くサクっとdiscardしてicmpも返さない糞ルータが
世の中にはたくさんあるからな。

世の中のルータがアホである確率をAとちたとき
n回ルータ通るときにアホに引っかからない確率
(1-(1/A))^n

1/Aって？

>>583
間違いだ

(1-A)^nだね

で、Aは？

A<<1
よって
1

でも、確立は確定じゃないからね

確率が確定する確率は確立してない

確率を確立する確率を書く律

リッチャアアアアアアアアアン！

PINGのような即答パケットの場合はタイムアウトはどれくらい取ればいいんだろう？
あんまり短いとタイムアウトが頻発するだろうし、
あんまり長いと応答待って次の行動を起こすような処理ではかなりの遅延になる

>>592
悪いが1秒だ

>>592
何が目的のＰＩＮＧなの？
593じゃないがゲームとか速度が要求される通信するなら
１秒超えるやつは無視でいいかもね

socket layer ってosi参照モデルのネットワーク層でいいんですか？

>>592
固まったのと勘違いしない程度にできるだけ長くだろ

>あんまり長いと応答待って次の行動を起こすような処理ではかなりの遅延になる

返事が来なけりゃ待つしかねえだろ

返事が要らないんなら、はじめから待つ必要ないし

>>595
ちゃいます
ネットワーク層からトランスポート層まで幅広く受け持っています > socket
ものによっては物理層までも

DION規制で遅レス(三週間前)になったけど、一応カキコ

>>524
もし真面目にネットワークプログラミングと付き合う気持ちが有るなら、
RFCが原典であることを忘れないでください。書籍はあくまでもRFCの解説書です。
(>>513等の)書籍でプロトコル仕様を「大まかに把握する」のはかまいません。
でも、そのプロトコル(今回はSMTP/POP-3)を実装する段階になったら、
RFCを読み通す必要があります。(読み通す必要性に迫られることになるでしょう。)

もし「RFC=英語 --> 難解」と感じているなら、たとえば「RFC 日本語」で
ググってみてください。有志による日本語訳サイトが見つけられるはずです。
有志(ボランティア)による翻訳ですから、細かい違訳/誤訳は我慢すること。
読んでみて「変だな」とか「意味が分からん」と思う箇所があったなら、
そこだけは辞書を片手にして原文(英語)にあたりましょう。
いくら英語が苦手でも、全文を翻訳する苦労と比較すれば、楽なものなはずです。
あるいは、ここで書籍(解説書)の助けを借りてもかまいません。
最後に、RFCの原文(英語)が原典であり、この日本語訳も参考にすぎないことを忘れずに....。

>>595
ソケット(socket)は、層(layer)ではなくてAPIとして分類される用語です。
OSI参照モデルは、その名の通り(抽象的な)階層化モデルであり、
TCPやUDPがトランスポート層に、IPがネットワーク層に対応(相当)します。
ですから、「ソケット層(soket layer)」という用語は、意味不明な誤った造語です。

なお、一般的にソケットといえば、TCP(あるいはUDP)のサービスを提供するAPIを指します。
ですから、

・(一般的に)ソケットはOSI参照モデルにおけるトランスポート層のサービスを提供する

というのが、適切な表現でしょう。

ただし、(>>597が書いているように)ソケットの実装によっては、
IPやEthernetを直接的に操作できるサービスを提供している場合があります。
これは「rawソケット」とも呼ばれ、自力でIPルータやEthernetキャプチャのアプリを
開発しようとする場合には、知っておく必要があります。

>>597>>599
お前ら優しいな
ありがとうよ

ところで、何作っているんですか？

>>599
元々のバークレイの思想だと 「ソケットは端点定義を抽象化した概念」
ソケット作って, ファイルにコネクトすれば open が出来上がるんだが

サーバープログラムでもクライアントプログラムも
close()やflush()はした方がいいんですよね？

>>603
close()は必須。flush()は程度による。

クライアントですぐ終了するならclose省略可能
サーバーは動作内容によってはcloseしないとfd足りなくなる
どっちにしても同時にいくつもプロセス起動した場合はfd足りなくなる恐れあり
出来るからといってやっていいかどうかは別

>>604-605
参考になったよ
感謝する

特定の通信手順を使ったデータ送受信アプリをWinsockを使って作っている
のですが対Winだと送受信とも問題ないのですが対Unix系だと送信が極端に
遅くなってしまいます。
Win(自作/他作) <--> Win(自作) 問題なし
Unix系(他作) ---> Win(自作) 問題なし
Unix系(他作) <--- Win(自作) 通信自体は成功するが遅い

多分send-send-ack問題だと思うのですが、これをWin(自作)の対策で
解決する方法はあるでしょうか?

２番目と３番目の違いは何？

まず「特定の通信手順」と「send-send-ack問題」という
>>607が(あるいは>>607の所属する組織が)定義した独自の用語を定義(説明)してくれ。
エスパーはいないから、スレ住人の各自が独自な推測を元に助言をすれば混乱するだけ。

「send-send-ack問題」とはこれの事。これを知らない>>609はモグリ。
http://www.samba.gr.jp/ml/article/sugj-tech/msg01326.html

レイテンシが重要な場合はnagleアルゴリズムを無効にすれば解決する。
http://support.microsoft.com/kb/214397/ja
> 多数の小さなデータ セグメントを一度に送信する必要がある場合、送信側で TCP_NODELAY オプションを設定します。

または
> データ配信を保証する必要がない場合は、UDP を使用します。

http://www.kt.rim.or.jp/~ksk/wskfaq-ja/intermediate.htmlも必読。

自分で答えを書いてるのでは？ｗｗｗ

モグリは引っ込んでろよ。>>608 != >>610

>>610
おぉー、リンクの紹介ありがとう。知らなかったよ。勉強になった。
WinSockには詳しくないので、モグリと言われてもしかたない。
というか、WinSockにはこんなクソな問題があるの？ポカーンという感想だ。

UNIXの場合、NODELAYオプションを使うのはtelnet/sshみたいに1文字単位での
データ交換の必要なプロトコルに限定して使われるよ。(だから「オプション」なんだ。)
リンク先の例にあるようなファイル共有やオンライントランザクション処理みたいに
パフォーマンス(性能)が重視されるプロトコルではNODELAYは指定しない。
NODELAYは「TCPスタックでのバッファリング機能を無効にする」という指示だからね。

これで自分は落ちる(ROMに廻る)ので、WinSockに詳しい住人さん達、
>>607へ良いアドバイスを与えてやってくださいませ。

厳密に速度が必要ならUDPを使うべきだよ
TCP自体が効率の悪いプロトコルしてる
ACK確認が取れるまで次のデータを送信しないからね
常に送信し続けて、ACKを並列的に処理すると数十倍の速度になる
しかし実装するのは難しいけど
作ろうとしたけどうまくいかない

サーバ側が他作だからTCP_NODELAYで逃げるのかね。
作り直すならSCTPも面白い。

暇なのでP2PのDHTを実装しようかなって思っているんですが、
それなりに難易度高いですかね？

>常に送信し続けて、ACKを並列的に処理すると数十倍の速度になる

ん？

＞TCP自体が効率の悪いプロトコルしてる
＞ACK確認が取れるまで次のデータを送信しないからね
このスレって知ったかでデタラメ言う奴多すぎ。

>>617,618

>>614はTCPを(ベーシック手順のような)交互応答プロトコルだと勘違いしているみたいだけど、
人にUDPを勧めておきながら(「UDPを使うべき」)、自分では実装できないレベルの人だから、
スルーしてあげるのがいいのではないかと思われる。

>>619
違うの？ACK来なかったら再送するでしょ
再送分を送ってる間は結局待ってるようなもんだし
実質的に交互応答になってるんじゃないの？

それと実装出来なかったとは言ってないTCPより早く出来なかっただけｗ

>>620
「ウインドウサイズ」とか、
その制御の仕方はご存じですか？

>>620
>それと実装出来なかったとは言ってないTCPより早く出来なかっただけｗ

「厳密に速度が必要ならUDPを使うべき(>>614)」であり、それを実証しようとしたけど、
失敗した(「TCPより早く出来なかった」)のだろ？当初の目的が達成できなかったのだから、
それは一般的に「実装できなかった」と呼ぶのだよ。動かなかったなんてのは論外だ。
この期に及んでのいい訳は見苦しい。

「特定の通信手順」はDICOMという医療関連の規格なのですが、すでに多くの対応ソフトが
存在するので問題はこっち(自作)側で対応する必要があり、今回の質問となりました。

「TCP_NODELAY」は受信側が遅延ACKをやめて即ACKするためのものと思ってましたが、送信側が
ACK待ちしない為のものだったのですね。確かにこれならうまくいきそうです。
ただし、今回問題となったUnix系サーバとの接続テストは、次回何時やるか分からないので
実際の動作確認はすぐには取れそうにありません。

>>623
パケットキャプチャソフトで覗いてやるということはしないのか？

想像だけでやってるよりよっぽど近道だぞ

>>623
まず、send-send-ack問題も知らずに定義の説明を要求した(>>609の)失礼をお許しください。

次に、DICOMは初見でしたので、サイトから日本語訳の巻1/7/8をダウンロードして読んでみました。
TCP上にOSI上位層スタックを乗せた、いわゆる「OSI-over-TCP/IP」の典型例に見えます。

で最後に、今回の性能劣化という障害に関する原因調査と対応策について検討します。

まず原因調査については、性能劣化の原因が「本当に」send-send-ack問題なのかを確認する必要があります。
確実な方法としては、以下の２手法によって上位(入力)側と下位(出力)側でトレースを採取し、それら付き合わせます。

・自作プログラム内にあるソケットへのI/Oとイベント待ち(select)の前後にタイムスタンプ付きの
　ログ採取コードを追加して実行し、そのイベントトレースを採取する。
　さらにTCP_NODELAYオプションが無効/有効という2通りでもイベントトレースを採取し、オプション指定が
　有効であることを確認できるようにする。

・(>>624が指摘したように)LANアナライザ(パケットキャプチャ)とTCPの有識者が手配可能で、
　なおかつサーバー連動テスト環境への持ち込みが許されるのであれば、それを活用してIPパケットの
　出力タイミングに関する(タイムスタンプ付きの)トレースを採取する。

もしsend-send-ack問題が原因であるなら、上位での(ソケットへの)送信要求がTCPスタック内で保留され、
いくらかの遅延時間が経過した後に、下位での(ネットワークへの)IPパケット送信が記録されているはずです。
そして、TCP_NODELAYが指定されている場合には、その遅延時間がほぼ0(数10ms程度)に収まるはずです。

(続く)

(>>625の続き)

次に、原因がsend-send-ack問題であると仮定して(...を前提にして)、対応策を検討します。

まず、DICOMという既成のプロトコルが前提になりますから、TCP以外のプロトコル(UDPあるいはSCTP)を
使うという(>>614,615の)提案は却下せざるをえませんね。

となると>>615が指摘しているように、TCP_NODELAYで「逃げる」という対処的な方法で解決するしか
ないでしょう。使い物にならないほど性能が劣化したシステムよりは、そこそこの性能が達成可能であるほうが
望ましい訳ですから。この段階が最初の対応策になります。この段階の性能値で満足できるなら、ここで終わりです。

次に性能改善(チューニング)を検討します。改善の着目点は、常にTCP_NODELAYを指定するのでは無く、
必要に応じて(あるいは、逆に不要な場合を除いて)動的に有効/無効を指定できる条件を見つける事にあります。
以下は、その例です。もしDICOMプロトコルの専門家に頼れば、他の条件も発見してくれるはずだと思います。

・アプリケーション層のメッセージがプレゼンテーション層で複数の断片に分割された場合、
　それら一連の断片は、ソケットへの複数のsend操作へと対応付けられることになるはずです。
　ここで、TCP_NODELAYが必須になるのは最後の断片のsend操作だけあり、それ以外の断片は
　TCPスタックの送信バッファリングに任せたほうが性能は改善されるはずです。

・PDUを符号化する実装において、ある単一の送信PDUを複数のsend操作で実現しているロジックがあれば、
　それらをすべて洗い出します。これらも(先の例と同じ理由によって、)最後のsend操作以外では、
　TCP_NODELAYを無効にしても無問題であるはずです。

>>623
＞「TCP_NODELAY」は受信側が遅延ACKをやめて即ACKするためのものと思ってましたが、送信側が
＞ACK待ちしない為のものだったのですね。

まだ違うよ。

send-send-ack問題なんてそんなの用語として確立しているものじゃないし、
そんなバグは今時のWinSockでは当然の事ながら解決されてるだろ。
パケットキャプチャもやらないで「たぶん〜問題のせい」ってモグリにも程
があるって感じ。

納得行くまでやらせて桶

DICOMの仕様まで調べてもらってありがとうございます。
現時点の実装では1PDU毎にsendするようになっていて全体の流れは次のように
なっていると思われます。

Win(自作)からの送信時
接続 Win(自作)からサーバへconnect
send ASSOCIATE
recv ASSOCIATE
send DATA イメージデータを複数PDUに分割し連続して送信する(現実装では4096バイト)
send DATA
send DATA
:
send DATA
recv DATA
send RELEASE
recv RELEASE
切断

Win(自作)が受信時はこちらがサーバ側となり上と逆手順となります。

次回テスト時は、TCP_NODELAYのOn/OffやDATAの1PDUサイズを調整したり、ログ出力とか
出来るようにしいろいろ試してみたいと思います。
また、みなさんが言われるようにパケットキャプチャを行なえる環境を準備できるか
調整してみたいと思います。

環境準備って、フリーソフトでいいがな

ソケットディスクリプタはソケットを識別する物ってことで、おk?

ファイルディスクリプタみたいなもの

同じものみたいな

>>598
ご丁寧なお返事、ありがとうございます。
おっしゃるとおり、書籍は所詮「概説」でしかない事は読んでいて実感しているところです。
特に>>520の御指摘どおり、MIME関係は本当にややこしい＆本には書いてないコトだらけですね。

RFCの日本語訳については、googleの先頭に出てくるのが↓ですね
http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
細かいコマンドなどについては、こちらで逐一確認することにしましょう。
ありがとうございました。

メールは世の中に適当実装があふれてるから
それ全部対応しないといけないし勉強とかが目的ならあまりお勧めしない
何年も掛かる

>>636
指示されたエンコードで可視可したら文字化けﾄﾗｯﾌﾟ　ですな

>>635
> http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html

ひさしぶりに眺めたらこれにワロタ

RFC 864 文字が湧いて出るプロトコル

>>637
半角カナを平気で使うリテラシの無いユーザもいるから、メーラの実装は大変だよね

WinsockとUDPを使った送信プログラムを作成しています。
ある異常系の試験を行っていて気がついたのですが、
サーバーへの接続後、サーバー側のLANケーブルを抜いた場合の挙動が
OSによって異なることが分かりました。

具体的にはWindowsXPではsendtoでデータを送信しても即座に処理を戻すのですが
（GetTickCountでとると0ms）
WindowsVistaや7では500msから3000ms程度sendto関数の応答が帰ってこなくなりました。

UDPは信頼性がないため、送りっぱなしと思っていたのですが、Vista以降の
ネットワーク実装が変わったんでしょうか？？？（ICMPでもチェックしてる？？？）

スレチならすいません・・・

>>640
vistaからarpの挙動が変わったようだけど。

>>641
レスありがとうございます

↓この辺が関係ありそうですね。
http://support.microsoft.com/kb/949589/ja
調べてみます。

>>639
本文に使用する分には問題なくね？

「問題なくね？」とか書く30代がきもいんですが。

本文に半角は問題ありますが、人格を責めるような書き込みがきもいです。

「きもい」なんて表明しないと気が済まない人がきもいんですが。

>>640
> 具体的にはWindowsXPではsendtoでデータを送信しても即座に処理を戻すのですが
> （GetTickCountでとると0ms）
間に何が入っているかにもよると思うんだが

>>640
別々のネットワークに置いても、挙動は同じなの？
っと。

はぁ？

低レベルなパケットのやり取りをすると
いくら待機を制御しても連続してパケットがくるとCPU使用率が１００％になる
本来ならカーネルがやってるからCPU使用率には反映されないだけなんだろうけど
ユーザーサイドのアプリケーションだと出てくる
結局は同じことだとしても気持ちが悪い
CPU使用率を下げる方法ってあるの？

>>650
カーネル、ユーザランド間の状態遷移。イベント通知、全然同じじゃない。

>本来ならカーネルがやってるからCPU使用率には反映されないだけなんだろうけど

？？？

>>652
パケットの並び替えとか再送処理とかをカーネルモードドライバがやってて
ドライバのCPU使用率は画面には出てこない
小さいパケットをループで回して処理するようなことをユーザーアプリでやったら
CPU使用率に反映されて１００％になる
カーネルレベルでやろうがユーザーレベルでやろうが同じことをやろうとしたら
リソースコストは同じだけども、見た目が悪いのでCPU使用率に反映させない
方法はないものだろうか

sleepはさめばいいんじゃね

>>654
sleepしたら通信が遅くなるでしょ

> 連続してパケットがくるとCPU使用率が１００％になる
連続してパケットが来たときに、自前処理やってるんだから100%になっても不思議じゃないよね。
その処理分を「CPU使用率」から除外したいってこと？

無理なんじゃね？

>>653
>カーネルレベルでやろうがユーザーレベルでやろうが同じことをやろうとしたら
>リソースコストは同じだけども

違うことをやってるから、結果CPU使用率が異なるんだとは思わないんだろうか。

専用のドライバ書くとかｗ

え、これってネットワークが鬼畜に速いかPCが遅すぎるとかいう話？
それともリアルタイムで糞重いエンコーディングとか画像処理系のフィルタリングかけてるとか？

だったらもっと速いPC買おうぜ
要するに処理能力が足りてないんだよ

>>659
UDPデータが連続して来るのにネットワーク速度はあんまり関係ないよね
ローカルLAN同士の通信で1000バイトやそこらのパケットの連続を
ループでまわすと処理の大小はあんまり関係ないと思うのだけど

sleep っつーか yield 挟むだけでも遅くなるような処理なの?
そんな膨大なデータやりとりするなら、しゃーないんじゃないかなあ

え？UDPの話なの？

UDPでsocket使ったユーザレベルアプリがCPU使用率100%になるって話？

UDP受信ね

なんかこの話題振ってる人不愉快

>>653
CPU使用率って誰が管理してんの？

単に非blockモードでreceiveを連続的に発行しているから
CPU使用率が100%になっているだけだと推測。
selectあるいは(Win32の)イベントオブジェクトで
UDP受信を非同期処理で実現していれば、
(一般的には)CPU使用率が100%になることはありえない。

>653
>>見た目が悪いのでCPU使用率に反映させない方法はないものだろうか

　今日の晩ご飯はカレーライスがいい、カレーライスじゃなきゃ絶対にイヤダ！！

と言っているガキの戯言にしか聞こえない。あるいは、

　中間試験の英語と数学で赤点をとってしまった。母親に知られるとやばいので、
　それを隠し通せる方法はないものだろうか？

でもいい。質問の内容がプログラミング相談室向けでは無い。
お子様向け人生相談室に合う話題だ。

>>667
もちろんロックを実装して何も無い時にCPU負荷が上がらないようにしてるけど
データベースの１レコードを１つのパケットにして何十件かをまとめて送るんだけど
もちろん転送効率を落としたくないから可能な限り早く発送して再送をする
ローカル環境では50ミリ秒前後の遅延がロスが少ない感じだけど
この頻度でも受信側はループして処理すると１００％になるよ

>>669
プラットフォームはWindows(WinSock)でいいのかな？以下、Yesとして答えるよ。

>>もちろんロックを実装して何も無い時にCPU負荷が上がらないようにしてるけど
ロックというのはWin32 APIのクリチカルセクションのことかな？
これは資源の排他制御に使う操作だから、これをループに組み込めばCPUを無駄に消費するのは当然。
>>667で書いたように、selectあるいはイベントオブジェクトで実装する必要がある。

>>667はそういう意味で言ってないよ
言語はC#でWaitHandleというものがある
恐らくWaitSingleObject APIをラップしたものだろうと思う
確かにコストは大きいけどCPU使用率に極端に影響するほどのコストではないと思うけどな

どっちかというと受信したデータを加工する作業が負担になってるし
これは省略出来ない処理なんでどうしようもない

>>650
kernelでCPUを喰っているなら、HWを買い換える。
userでなら、糞なprogramを書き換える。

Windows のコマンドラインアプリで netsh ってあるけどこれってシスコＣＬＩみたいだなーと思ったら、まんま移植したものっぽいね。
netsh ってWindowsでサーバー構築してる人が使うものなんですか？

べっ、別にサーバー以外で使ってもいいんだからねっ

Winsock2について質問です。

クライアント側で FD_CLOSE が呼ばれるのはどういうときでしょうか？
・サーバ側がclosesocketしたとき
・サーバ側がshutdownしたとき
・クライアント側がclosesocketしたとき
・クライアント側がshutdownしたとき

>>676
上３つじゃね

何故ドキュメントを読まないのだ。

http://msdn.microsoft.com/en-us/library/ms741540(VS.85).aspx
The FD_CLOSE message is posted when a close indication is received for
the virtual circuit corresponding to the socket. In TCP terms, this means
that the FD_CLOSE is posted when the connection goes into the TIME WAIT or
CLOSE WAIT states. This results from the remote end performing a shutdown
on the send side or a closesocket. FD_CLOSE should only be posted after all
data is read from a socket, but an application should check for remaining
data upon receipt of FD_CLOSE to avoid any possibility of losing data.

誰か訳してください

プログラミングは中学卒業してからにしましょう。

>Winnyの場合，待ち受けポート番号は1024番以上からランダムに選ばれます。
何故、ランダムに待ち受けポートを変更しても通信が出きるんですか？

>>680
英語力も高くなるよ、まじめにプログラミングすれば…

>>681
相手が何番ポートか分かってるから。

いやそのポートの話じゃねえし

ランダムに待ち受けポートを変更しても「相手が何番ポートか分かってるから」。

>>681
その選んだポート番号と自分のIPアドレスを自ノード情報として拡散するから。

>>679
>>678を訳してみた。専門用語が理解できていれば、高卒レベルの英文法の知識で十分ではないかと思われる。

>The FD_CLOSE message is posted when a close indication is received for
>the virtual circuit corresponding to the socket.
　　FD_CLOSEメッセージは、ソケットに対応する仮想回路からclose通知を受信した時に通知される。
>In TCP terms, this means that the FD_CLOSE is posted when the connection
>goes into the TIME WAIT or CLOSE WAIT states.
　　TCPの用語で言い換えれば、これは接続がTIME WAIT状態またはCLOSE WAIT状態へ遷移する時に
　　FD_CLOSEが通知されることを意味する。
>This results from the remote end performing a shutdown on the send side or a closesocket.
　　これは送信側のリモートエンドによるshutdownの実行、あるいはclosesocketに起因する。
>FD_CLOSE should only be posted after all data is read from a socket, but an application
>should check for remaining data upon receipt of FD_CLOSE to avoid any possibility of losing data.
　　FD_CLOSEはすべてのデータがソケットから読まれた後にのみ通知されるはずであるが、
　　データを失う可能性を避けるため、アプリケーションはFD_CLOSEを受取り次第、
　　残りのデータが存在するかを確認すべきである。

自演乙

＞これは送信側のリモートエンドによるshutdownの実行、あるいはclosesocketに起因する。
つまりどういうことですか？

>>689
リモート側アプリケーションが恣意的に回線を閉じたということ。

それともshutdownとclosesocketの意味が分からないのかな？

× 送信側のリモートエンドによるshutdownの実行
○ リモートエンドによる送信面のshutdownの実行

つまり、相手側がshutdown(sock,SD_SEND); 、またはclosesocketを実行した場合ってこと？
相手側がshutdown(sock,SD_RECEIVE); を呼んだ場合や、自身がclosesocketを呼び出した場合はFD_CLOSEは発生しないって事ですか？

TIME_WAITに遷移するのは自分がcloseした時。従って自分がclosesocketした時も
FD_CLOSEが飛んでくるはず。

test

http://ymir.la/loda/src/ymir_10144.zip.html
たとえば上のサイトでは　ダウンロードキーに　moemoe と入力すると
ダウンロードできるようになりますが、
これをプログラムで行うにはどのように行うのでしょうか？

>>695
先生、病院はこっちです
ttp://www.pri.kyoto-u.ac.jp/index-j.html

夏だな

めんどくさいんです＞＜
お願いしますｍ（＿ ＿）ｍ

お前みたいなバカの相手するのが、皆めんどくさいんです＞＜

>>695
そのページだと>>695レベルじゃ作れないかもな〜
cookie関係のプログラミング面倒くさいもん

LLで作るんだろうけど、www::mechanizeでも調べればいいと思うよ

説明できないほどのどアホなんですね＞＜
すいませんでしたｍ（＿　＿）ｍ

>>700
LLって何の略？

あーなるほど、Lightweight Languageの略なのか
bashとかwshとかああいうののことか。知らなかったわ

アホなのでレスの内容が理解で来ませんでした＞＜
すいませんでしたｍ（＿　＿）ｍ

おまえらのようなクソゴミ役立たずに質問するよりも
買ったほうが作者にもいいし、経済にもいい
つまりおまえらはアマチュア同人作家以下のとんでもなくくっさいゴミむしのキチガイがはいたゲロを
食べて生きている下等生物以下のミジンコの卵
さっさとクソしてしね

プログラミングに必要な能力は技術じゃなくて根気
面倒臭がってたら何も産み出せない

それだけじゃない。

意外と適性も必要らしい。

>>705
これは、俺になりすました人です
迷惑かけてごめんなさい

>>706
下手な根気は誤った方向へ延々とハマるという場合もある。
適度に「これめんどくせ〜、もっといい方法無いかな？」というのも必要。

>>710
いい方法ばかり探しすぎて何をすればいいのかわからなくなって何もできないのがお前

>>711
自己紹介乙としか

>>711
「めんどうくさがり」ってのはプログラマーに必ず必要な資質

いい方法を探すのすらめんどくさいやつはどうするの？

>>714
それは「めんどうくさがり」ではなく、ただの「なまけもの」だ。
一見そっくりだが大きな違いがあるので注意しよう。

へりくつだな

屁理屈も理屈のうちだよ

それもまたへりくつだな

その屁理屈も理屈のうちだよ

それもまたまたへりくつだな

ただ、めんどくさがるだけじゃ何もならない。　めんどくさがる為に手を動かすという資質が必要。　
めんどくさがらずにめんどくさがる。　

それはめんどくさがりとは別の資質だ
改善したがりという資質だ

めんどくさがりは向いていない

そのとおり

>>715
じゃあ、めんどくさいから他人に仕事を押し付ける人はめんどくさがり？

PacketShader
GPUを利用したPCベースのソフトウェアルータで40Gbpsを達成

http://shader.kaist.edu/packetshader/

これからはネットワークプログラミングもGPGPUの時代ですよ！

しかしGPGPUってハックだよなぁ。
元々GPU自体は画像処理のための物だし、
CPUが超並列化してくれる方が正統だと思うんだけどなぁ。

頭が固いと苦労するぞ

頭が堅い俺はCometが流行った時も批判しまくってた。
今ではHTML5で遊んでる。

下記と同じようなことをCLRアプリで実現させたいです
HttpWebRequestでやって見ましたがCookie関連の動作がうまくいきませんでした

例えばYahooにアクセスすると下のコードでは
こんにちは、○○○さん
となるのに対しHttpWebRequestだと
ログイン
になってしまいます

誰かお願いしますm(_ _)m

AfxParseURL(CString(uri), protocol, serverName, fileName, port);
CInternetSession session(L"HttpPost - simple http client");
CHttpConnection* conn = session.GetHttpConnection(serverName, port);
CHttpFile* file = conn->OpenRequest(
CHttpConnection::HTTP_VERB_GET, fileName,
NULL, 1, NULL, NULL, INTERNET_FLAG_RELOAD | INTERNET_FLAG_DONT_CACHE);
file->AddRequestHeaders("〜");
file->SendRequest();

酷い翻訳だな。機械翻訳かと思ったわ
ttp://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=JA-JP&k=k%28SYSTEM.NET.SOCKETS.SOCKET.SHUTDOWN%29;k%28SHUTDOWN%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22%29;k%28DevLang-CSHARP%29&rd=true

MSDNは基本的に機械翻訳だが？

ｸﾗｲｱﾝﾄ側のﾌﾟﾛｸﾞﾗﾑ作ってﾃｽﾄしたいがｻｰﾊﾞ側となる機器が手元に来ない
でも、自分でサーバー側応答ﾌﾟﾛｸﾞﾗﾑを書くのは面倒くさい。
こんなときに使えるらくちんツールって無い？

VM

めんどくてもサーバー側は作る

>>733
inetdやxinetdを使う

テスト用の返答返すだけならクライアント書くのと大してかわらんだろう？

結構違う場合もある

ｄｊｂのツールにいいのが有ったような

>>733
プロトコルがテキストならnetcatとか。

dhtの実装って難しいのか

広く、といっても資格の勉強などはおすすめしません。資格というのはあくまで仕事に直結したものを取るべきです。
採用時に資格は一切評価しないといった建前も世間ではよく耳にしますが、折角の機会ですから本当の事を言います。評価します。マイナスの評価です。
仕事に就いていないのに資格の取得などに時間を浪費していたという事実は、少なくとも一分一秒を争う企業活動への参加を目指すなら、悪です。
学生時代のいまから時間の使い方をしっかり意識して生活してください。
社会に出れば仕事を覚えるために学生時代の１０倍も２０倍もハードな勉強が求められます。
もちろん必要な資格があればその中で取得します。しかしその学習量は社会人が仕事の中で日々習得する知識量のうちのほんのごく一部に過ぎません。
学生が資格の勉強に貴重な時間を費やすのは、子供が折角もらったお年玉を老後の生活資金に貯めておくようなものです。
子供のお小遣いと大人の生活費では一円の重みが違います。同様に、学生と経験を積んだ社会人とでは同じ一時間でも脳の仕事量が全く違うのです。

どこの誤爆

まだ人間じゃない

>>742
お前ニートだろ？ｗ

天才プログラマいる？

>>746
俺天才プログラマだけどなに？

俺超天才プログラマだけどなに？

天才を超えたら天才じゃないじゃん。

おれ人災プログラマだけどなに？

>>750
あんま迷惑かけるなよ

MessagePackをネトゲプロトコルに使おうと思うんだけどどう思う？

>>752
テーブルゲーム系ならいいんじゃね？

ipsendwinというツールを使ってパケットを飛ばしてテストをしていたのですが、
ツールを終了してもパケットの送信が止まらずに困っています。
パソコンを再起動しても止まりません。
どなたか解決方法を知りませんか？

バグってんじゃね？

>>754
パソコンを再起動しても止まらないなら、それは受信側が悪い。

受信側のせいでパソコンを再起動しても送信が止まらなくなる。。。
悪魔祓い師を呼ぶしかなさそうだな。

受信側のバグで送信し続けてるように見えるんじゃね？ってことだろ。
本当にツールを終了してもPCを再起動しても送信し続けてたらそっちの方がオカルトだわ。

質問です。

HTTPでファイルをダウンロードしたとき、
サイトにファイルのチェックサムなどが書いていない場合、
正しくファイルがダウンロードできたかをチェックする方法ってありますか？

もう一度ダウンロードして比べてみるか、壊れていませんようにと神に祈る
いちおうTCPのレイヤではチェックサムを確認しているはず

TCP的には内容が壊れてないことと順序は保証されてるはずなので、
Content-Lengthヘッダと、実サイズが合ってれば壊れてないはず。

>>760
なるほどTCPは信用できますが、
プロキシを通して間接的にHTTPをやりとりしている場合はどうなのでしょうか。

>>761
> Content-Lengthヘッダと、実サイズが合ってれば壊れてないはず。
サイズで比較するのは良いアイデアですね。
早速実装してみたいと思います。
ありがとうございました。

イラっとくるな、こいつ

>>763
未熟者でして、イライラさせてしまい申し訳ありません。

信用できないプロキシを使うユーザが悪いということにすればいいです

実装してみましたが、プロキシ経由の場合はヘッダが書き換えられていて
内容が壊れているかどうかをContent-Lengthで比較してもわかりませんでした。

だからチェックサムがあるんだよ。
わかれよそれくらい

俺の股間にチェックサム！！！

毎度大量のﾊﾟｹｯﾄを破棄するのですな。

信用できないproxy挟んでいた場合、ファイルの内容やContent-Lengthどころか、
ページ内容のチェックサムだって改竄されている可能性だってあるぞ。

いろいろレイヤが混ざってるが、
・HTTP的にファイルが完全にダウンロードできたかどうかは、Content-Lengthのチェックで十分。
もしContent-Lengthが無かった場合は、HTTPのコネクションが切れた時点で転送終了と見なすしか方法はない
・ファイルの改竄を防ぐには信頼できる鍵でSSL使うしかない

>>770
そういうことは実際に野良プロキシ大量に扱ったあとに言いなさいよ。
ファイルが壊れる原因は一度のアクセスでの転送量に制限を加えている鯖が多いからだよ。
悪意で改竄する鯖はほとんどない。

悪意があるないなんてどうでもいいし>>770もそんなことに触れてない

悪意があろうとなかろうとHTML以外のファイルの内容を破壊せずに弄る野良プロキシは多くない。

>>771
そもそもそれ立派な悪意だろ

>>774
いや、悪意じゃないでしょ。
通信量は有限なんだし、パンクしないように制限を加えるのは合理的だよ。

×　通信量
○　帯域

>>775
合理的では無いだろ

うん、日本語が変だ。
そこで合理的という言葉が出てくるのはおかしい。

じゃあなんて言うんだよ。
WEBサーフィンの支援を目的とした中継サービスを広く提供することを目的とするなら、
ダウンロード目的の利用を牽制することも含めて
通信量に制限を加えて一回のアクセスが回線を占有し続けないようにするのは
手段として合理的だろ。

合理的か非合理的か、悪意か善意か、なんて問題はどうでもいいよ
必要なのは修正が加えられることがあるという事実にどう対処すればいいかってことだけじゃないのん

>>780
おっしゃるとおり。
改変が加えられることに対処する方法が無いから
ファイルのMD5をページに書いて自前で比較してくださいね、
っていうダウンロードサイトが多いんだろうなぁ。

プログラミングの話なの？

コードは出てこないけどプログラミングの話だよ。
技術的な話題。

winsock の質問はここでよろしいでしょうか？

WinSock 2.0 を使い、サーバ・クライアントモデルのアプリを作っています。
また、WSAAsyncSelect を使って接続を非同期にしています。

同じマシンでサーバとクライアントを両方立ち上げ、127.0.0.1 で接続すると正常に動作しています。
ところが、インターネット経由で接続すると、connect 時にメッセージで WSAETIMEDOUT が返ってきます。

IP は ttp://cgi13.plala.or.jp/hiro-mg3/ip.shtml で調べて接続しました。
（ルータを挟んでいるため ipconfig では自分自身の WAN 側のアドレスを取得できませんでした。）

LAN 側のアドレス （192.168.〜） では正常に動作しました。

ファイアーウォールを疑い、ルータの設定で全てのポートを開放、セキュリティソフトもオフにしましたが、結果は変わらずでした。

127.0.0.1 で上手く動き、インターネット経由では上手くいかない可能性として何が考えられるでしょうか…。

関係ありそうなソースは以下の通りです。
よろしくお願いします。

SOCKET sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
WSAAsyncSelect(sock, 〜, 〜, FD_ACCEPT | FD_CONNECT | FD_READ | FD_WRITE | FD_CLOSE);
sockaddr_in server;
server.sin_family = AF_INET;
server.sin_port = htons(54321);
server.sin_addr.S_un.S_addr = inet_addr("〜");
connect(sock, (sockaddr *)&server, sizeof(server));

>>784
それはルーター依存だ
ルーターによってはLAN側からWAN側のアドレスにアクセスできないものがある
最近の事情は知らんが、ちょっと昔はできるもののほうが少なかったよ

>>785
ということは、完全に外のマシンからなら普通に繋がる可能性もあるということでしょうか。
別環境を用意して試してみます。ありがとうございます！

TCP/IPについてなんとなくわかったつもりで体系的な知識をまるでもっていないと気付きました
勉強するのに良書があれば教えて下さい

>>786
router が間に挟まっていて, 複数アドレスもってなければ，
router の外側 == 割り当てられているグローバルアドレス
router の内側 == プライベートアドレス + あなたのマシンもプライベートアドレス
ってのが, 普通じゃないのか?

割り当てられているグローバルアドレスにパケット投げても router に行くだけちゃうか?
その, パケットを router がどう処理するかは router の機種と, 設定次第.

>>787
UNIXネットワークプログラミング〈Vol.1〉
を頭っからケツまで1文字も飛ばさずに読む。
読むだけでもいいからとにかく全部読む。

>>789
ネットワークプログラミングとTCP/IPの理解はまた別物
いい加減なレスはしないように

覚えたい目的はインターネット上で動かすアプリのデバッグでつまんないところでハマリたくないからだろ？
そうするとTCP/IPだけ覚えても、結構ハマるネタは残ってるぞ
その上にのっかってるDNSやらDHCPやらいろんな物の挙動も知っておかなきゃな


俺はそれっぽい本を見ながらlinuxマシンで実際にいじり倒して遊んで覚えた

一冊じゃもちろん無理だし、既存のソフトの動きを調べたり、色々やることあるよね

>>790-792
そういうのを全部ひっくるめて、一冊とにかく読めという話だ

だったらそう言えば？最初から
つっこまれて条件後出しは無様だよ

>>794
「頭っからケツまで1文字も飛ばさずに読む」しか書いてないよ。
それ以外の理屈は正直どうでもいい。とにかく読む。

じゃあ全部ひっくるめとか言い出すなよ
ほんとにカスだな

まったくだ。

何を言っているんだお前らは

本や資料を読む努力しない馬鹿はいい加減実務畑に来るなとしか言えない
しりませんは言い訳にならないのにいつまで甘えてるんだか

何を言っているんだお前は

誤爆？

ぎゃー、別のところで同じような流れだったんで誤爆したごめん

いまどきUNIXとか言われてもなあ

>>803
UNIXじゃないネットワークなんてねーよ

UNIXネットワークプログラミング(Vol.1)は池沼には理解できない。
池沼はネットワークプログラミングを行ってはいけない。
UNIXネットワークプログラミング(Vol.1)を読む事は資格試験。

>>805
理解できなかったのか？

>>806
キミでも100回読めば理解出来るかも知れませんよ。

おまいら全員黒猫だと思えば癒される

>>808 すまん黒猫の意味がわからん、教えてたもれ？？？

MMOの小規模な奴を作ってみようと思うんだが

クライアントはC、C++で作って
サーバーをどうするか悩んでる

OSはWindowsサーバーかLinuxか

多数接続する場合、ソケット1つにつき、スレッド１つ割り当てるか
Selectで一つづつ見ていく処理にするか

あまり高速な処理が要求される内容じゃないんだが
助言求む

各プラットフォームで最速な奴を使うべきだろ。
IOCP/epoll/kqueueとかその辺。

linuxには詳しくなかったからその辺勉強してみます
サンクス

>>810
もし「Linux＆小規模＆高速性は要求されない」のであれば、
マスタ・スレーブ方式のマルチプロセス構成でサーバを設計するのが、最も単純。
言い換えると、ソケット1つにつき、1つのプロセス(スレーブ)を割り当てる方式。
具体的には、Linux標準サーバのftpdやtelnetdがこの方式で実装されている。

各スレーブには独立した仮想メモリ空間が割り当てられているから、
スレッド方式と比較して安全な設計が可能だし、シングルプロセス＆select方式と比較すれば
イベント駆動制御も不要だから楽に設計できるし、デバッグも簡単といった利点がある。
欠点はLinux(UNIX)依存であることと、大規模＆高速性が他と比較して劣る事。

動作を簡単に解説すると、マスタプロセスがacceptで接続通知を待ち受け、
スレーブプロセスをfork&execする、というもの。(ApacheのCGIと同じ、と考えれば分かりやすい鴨)
あと、マスタプロセスは自分で開発しなくても、inetd(インターネットスーパーデーモン)に
接続待ち受け＆スレーブ生成をまかせ、スレーブだけをC/C++等で実装することも、場合によっては可能。

UNIXでは古典的な方式で、例題も豊富に有るから、最終的にどの方式を選択するかとは別に、
一度勉強しておくことを勧める。将来、きっと役に立つはず。
教科書なら、このスレの図書コーナー(>>2)にある
・UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
・TCP/IPによるネットワーク構築〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
あたりがバイブル的な存在で、個人的なお勧めかな。

サーバーには玄箱を使おうと思うんだが

無謀かな？

PowrePC　233M

無謀だわな・・

ゲーム内容はWIZのオンラインみたいなのを考えてるから
リアルタイム性はそんなに高くない

けど・・

玄箱じゃ無謀だわな

同時20人くらいならそのくらいのスペックでOKだったよ
コントロールやチャット程度ならね
画像もあると、ちと苦しい

PPC/233ってことは初代の玄箱で、あれってメモリが64MBしか搭載されていないよね。
そうであれば、

>多数接続する場合、ソケット1つにつき、スレッド１つ割り当てるか
>Selectで一つづつ見ていく処理にするか

のどちらか(= シングルプロセス構成)にしないと厳しいだろね。

それでも、ゲーム内容にもよるが、同時100TCPコネクション程度は耐えられるんじゃないかと思う。
もちろんメモリがキツキツだから、LinuxをDebian(Sarge?)に入れ換えて、
カーネル再構築や不要なデーモン停止といった、チューニング(スリム化)作業必須が大前提になるけど。

自分なら、安い中古ノートPC(Cell/700Mhzクラス)にメモリ512MBくらい入れて、>>813の
マルチプロセス構成にするんだけどね。まぁ検討しているうちが最も楽しいから、色々考えてみるが良し。

>>813
クライアント同士でのデータのやりとりが多発するMMOでクライアントごとにプロセスはないだろ・・・

>>817
まったくだ >>813 のド素人振りがよくわかるレスだよな

>>814
そのスペックあれば, ネットワークのレイテンシーさえビハインド出来れば問題ないよ
動的生生成ページでを秒あたり100程度のトランザクションは何とかなる
ただし, いかに2次記憶を動かさないかが腕のみせどころになるが………

全部UDPでやったろうか

パケット紛失しまくり

>>818　ならどういう設計がいいんだ？

いまゲームのロゴ用フォント作ってる
タイトルはWearezardryにしたい

フォント作り難しい・・・

しーん

>>810
クライアントのターゲットがWindowsなら、サーバーもWindowsにしておいた方が
コードを共有できる部分も増えてらくなのではないかと思う。
Windows Direct Accessとか使うと、楽できるかもしれないし。

クライアントの数が数百とかになるなら、
クライアント毎にスレッドを起こしていたらサーバーが持たない。

>>820
リアルタイム性の高いゲームならUDPもあり。
TCPで再送している間に遅延が起こるくらいなら、UDPで遅延したデータは捨てる。

>>817
いや、「単純」という文脈であれば間違ってないよ。

「スケーラビリティ」とかって単語が出てくるようであれば、
言語云々は別として、ステートマシンしかないけど。

Pythonが書けるなら、twistedをおすすめするのだが…

Wearezadryのロゴできたーうぉー
慣れないInkscapeと一晩格闘してやっとこできた・・
普段絵なんぞ触らんからスゲー時間かかったわ

どう？それっぽいかな？

http://uproda11.2ch-library.com/268426saK/11268426.gif

>>825
ねーよ

>>825
言語としてPythonはねーわ・・・

>>825
fork方式でプロセスわけちゃうとスレーブ同士のIPC通信が必要になるケースなんだから
全然「単純」にはならんのじゃまいか？

それとtwistedって並み居る非同期フレームワークの中で、何がいいの？
今だとnode.jsとかも流行りだけどさ
Pythonでもeventletなら、コルーチン＋モンキーパッチを利用して
非同期特有のコールバックでなく、同期のソケットとと全く同じpull型の
記述が出来るので、FSM書き下すより楽ですよって主張と受け取れるんだけどさ
eventletみたいなのは、さすがに動的言語でないと無理だなあと思う
ゲームでコルーチン使いたくてスクリプティングにluaとかが使われるのと同じだよね

なんか思いつきで適当なことホザいてるようにしか見えない

forkフルボッコでわらた

> それとtwistedって並み居る非同期フレームワークの中で、何がいいの？
楽なのはlibeventを使う方法
パフォーマンスも悪くない

>>831
いやそういうことじゃなくて
何でtwistedなんか薦めるの？という突っ込みだったんだが…

まあいいか（どうでも）

>>832
知るかボケ >>825 にレスしろよ

>>833
は？
>>831が俺(>>829)に（的外れな）レスをつけてるみたいだから答えただけなんだが？

>>834 = >>832 = >>829 かよｗ
どれも馬鹿まるだしのレスだなw

python って asyncore で間に合っちゃうよね
twisted に拘るメリットって何があるのか教えて欲しい
(煽りじゃなくてマジで)

今理解できてるものでやれ
何をデバグしてるのかわからなくなるぞｗ

>>826
剣が鉛筆みたいだ、そこいじればカコイイ

eventletもそれなりに重いがtwistedは選択技にすら上がらねー

なんでerlangが出てこないんだ

>>840
選択肢としてふさわしくないからでしょう。

Windows環境のJavaのソケット通信で質問させてください。

ソケット常時接続で通信を行うサーバ・クライアントモデルの
クライアント側アプリケーションを作っています。

OSはWindow 2003、JavaはJDK6を使用しています。

クライアント - サーバ間は、
[クライアント] - [スイッチングハブ] - [ルータ] - [サーバ]
という構成になっています。

クライアント側からアクティブオープンでソケット接続後、
常時read用スレッドおよび、write用スレッドの２つの非同期
スレッドでソケットを共有して使用しています。

ここで [スイッチングハブ] - [ルータ] 間のLANケーブルを
抜き、しばらくするとクライアントのread処理で例外
「SQLException(connection reseted)」が発生します。

Wiresharkで確認してみたところ、LAN線を抜いた後の
write処理でTCP PSHのリトライを繰り返しており、
リトライを7〜8回繰り返した後に、上記の例外が
出力されます。

このとき、クライアント側からFINもRSTも出力されていません。
クライアント側の実装で、shutdownもcloseもしていませんでした。

別途クライアントをJavaのプログラムからWinsock2.0を使用した
ツール(SocketDebugger)を使用してサーバに接続し、LAN線を
抜いた後にツールからデータ送信(write)を行ったところ、
Wiresharkのログは上記と同じものが出力され、ツールには
WSAECONNABORTED(10053)が発生したと出力されました。

WinsockがTCP PSHのリトライオーバによりソケットを
破棄したものと思われるのですが、このソケットの破棄が
行なわれないようにすることは可能でしょうか？
可能な場合、どのようにすればよいか、ご教示願います。

上記現象でソケット破棄されることがWinsockの仕様(避けられない)
場合、TCPのリトライ回数やリトライ間隔(時間)を増やすことは
可能でしょうか？

以上、よろしくお願いします。

頑張ってる様子が伺えるが、混乱してるよ。例えば

・「SQLException」->SQL使ってんのか。通信の上にいろんなのかぶりすぎでは
エスパー以外わからんよ。
・「ソケットを破棄したものと思われる」->「思われる」じゃだめだろ。
ここが発端で「ソケット破棄を防ぐには〜」とおかしな方向に行ってる。

察するところ
TCP接続が切れてもアプリとしては何事もなかったように通信を続けたいのか？
それなら、エラーを適切に判断して適切に再接続して元の処理に戻るだけ。

（俺が作るなら関数コールでの制御じゃなくて状態変数を使って制御するが
それはまあ別の話）

アドバイス：
いきなり難しいことをやろうとして技術が追いついてないっぽいががんばれ。
自分が作ろうとしてるものをちゃんとレイヤ化して考えといい。
エラー発生箇所をもっと（OSのAPIまで）絞り込むくせをつけるといい。

一時的にケーブルが引っこ抜けたとしてもTCPのコネクションは切断したくないって話じゃないかなぁ

大事なこと削っちゃった。

ソケットは「破棄」されてないと思うぞ。

>>845 それなら、
・接続時にキープコネクションを有効にせず
・切れてる間に一切通信しようとしなかった
なら可だが、それ以外なら無理ジャネーノ。

まずは本人が何をやりたいのかだな

みなさん、回答ありがとうございます。
つたない内容の文章を読んでいただき恐縮です。

>> 844 さん
「SQLException」は、「SocketException」の誤りでした。
　申し訳ありませんでした。

> 察するところ
> TCP接続が切れてもアプリとしては何事もなかったように通信を続けたいのか？

　ご指摘の件ですが、私個人としては「例外を検知したので、
　ソケットの再接続を行う」という実装にしたい(している)のですが、
　サーバ側のアプリ開発の方から、
　「経路のチェックは、アプリレベルのヘルスチェック送受信の
　　タイマーでのみ管理すべきであり、それ以外の制御下でソケットを
　　切断することは、基本認められない」と言われており、

　>> 845 さんが言われました、
　> 一時的にケーブルが引っこ抜けたとしてもTCPのコネクションは
> 切断したくないって話じゃないかなぁ

を実現する方法がないかを模索しているところです。

＃ アプリレベルのヘルスチェックについて、前回説明しておりませんでした。
　　申し訳ありません。

＃ またヘルスチェックのほかに、アプリレベルで電文の
　送達管理(電文送信時、相手から電文受信電文が送付される)
も行っております。

さらにサーバ側アプリ開発者からは、
「Javaで実装しても、LANケーブル断線時にソケットが
勝手に切断されることはないはず」
ということを言われ、できる術を探しているところです。

＃ サーバ側開発者の方に対策方法を聞ければよいのですが、
　 立場的に聞けない関係なのです・・・。

現状、調査があいまいな状況なのですが、私見では
>>847 さんが言われた
> ・接続時にキープコネクションを有効にせず
> ・切れてる間に一切通信しようとしなかった
> なら可だが、それ以外なら無理ジャネーノ。

ではないかと思っております。

いずれにしても、>>845 さんからもアドバイス
いただいたとおり、もう少し深く調査し、原因を
絞り込んでみます。

宿題は宿題スレへ

>>849
原因と言うか、送信タイムアウトでソケットが切断されるのはTCPの仕様なので、
その要求を満たそうとするなら必然的にTCPを使用しないと言う選択肢しかないと思うよ。

通信経路のヘルスチェックが、厳密にはソケット自身でしか出来ないですしね。
間に介在しているすべてのルーターやHUB、プロキシをクライアント側の
ヘルスチェックでどうこうできるものでもないし。

とりあえず、その要求仕様を突き付けている馬鹿に、サンプルプログラムでも
書いてもらうしかないじゃない？

その要求仕様を突き付けている馬鹿は >>849 自身のことだろ

だから

>＃ サーバ側開発者の方に対策方法を聞ければよいのですが、
>　 立場的に聞けない関係なのです・・・。

こんなことになってんだよw

サーバ屋さんが言ってるのが正しく、切断はされないと思う。
ケーブル抜いてタイムアウトしたら、writeかreadでEWOULDBLOCKが返ってこないか?

ただし、期間が余り長いとDHCPのリース期間終了とか他の要因で切断はある。

>>842
こんなのあった。
http://support.microsoft.com/kb/931319/

Windows で TCP/IP のメディア検出機能を無効にする方法
http://support.microsoft.com/kb/239924/

んゆ。

>>855
無効にならねーよバカ

メディア検出は、サーバPCもクライアントPCも有効のままだよね。
PCが直接つながってる線のリンクはダウンしないって話でしょ。



手元の資料によるとPosix.1gのTCPソケットオプションで
TCP_MAXRT っていうのがあって、
「TCPがデータの再送を開始してからコネクションが切断されるまでの
時間を指定する。値にゼロを指定するとシステムのデフォルト値を用いる
ことを意味し、-1を指定すると永久に再送を行うことを意味する。…」

とある。けど、Windows2003についてくるWinsockのTCP実装が
TCP_MAXRTを実装しているかは未調査。あと、Javaで指定できるかも
微妙。

ttp://download-llnw.oracle.com/javase/1.4.2/docs/guide/net/socketOpt.html
には載ってない。

>>851 さん
その後、サーバ側のアプリ実装者からソケットの実装処理を
抜粋し、紙で提供していただく機会があったのですが、
java.net.Socketを使用した一般的な実装で、特別なソケット
オプション指定やロジックを使用しているようには見えない
ものでした。

その実装で、問題（TCP自動切断）が発生したことがないと
言われており、ますます混乱しているところです・・・。
（その方の実行環境は、WindowsXP SP3だそうです。）


>>852 さん
私がその立場にいたのでしたら、「すいません」と言って
仕様変更するという調整もできたかもしれないのですが・・・（；_；）

>>853-857
情報提供ありがとうございます。
現在行っている調査の参考にさせていただきます。

＃ 進展のない話を書いてもスレ汚しですね。
　　調査結果がなんらか出てから書き込むようにします。

Windows
http://support.microsoft.com/kb/158474
MaxConnectRetries
MaxDataRetries
Linuxなら
tcp_retries1,tcp_retries2とか？

リトライ回数=無限を設定できない限り解決にならないし
大きな値を設定したとしてもリトライ間隔がえらいことになるぞ
（リトライ毎にタイムアウト時間が倍々になったり。。。）
ワケの分からないことは止めて普通に再接続処理しなきゃダメだよ

winsockで質問です。
相手から送られてくる文字列って何バイトか分からないと思うんです。
なので、あらかじめ文字列バッファを適当に確保しとくしかないと思うんですが、
なんとか送ってきたデータのサイズをチェックして動的確保したバッファにrecvできるような
方法ないですか？

それを書くのがプログラマの仕事だ

わかったよ

>>862
最初にバイト数を書いといてもらう
で、バイト数が書いてある所だけ読んで確保する

>>865
素晴らしい発想ですね。ありがとうございます。

つ[車輪の再発明]
HTTPって本当に良く考えてるなと思うわ

俺は学校で行なわれている教育を車輪の再発明とは表現しないが、する人もいるのかな？

>>867
なぜそこでHTTP・・・
ストリームもので必ずついて回る問題だから
車種も無限にあるし、車輪は無限にあるよ

HTTPは>>862の要望にはそぐわないけどな。
ヘッダサイズが不明だから。

「車輪の再発明」と言い出す奴は「私バカです」と言っていると思っても、99%までは間違いない。

>>868
ここは学校じゃないぞ？宿題スレでもないし

MacBinary は偉大だったというオチ

>>869
でも解決策は無限にないよね
どれもこれも似たような解決策ばっかり
まあ、ひねったプロトコル書かれても面倒くさいだけなんだが

すごく重要なサーバーを書く場合はやっぱりCが一番かな
C#とかJavaは危険かな

危険ねえ

危険か安全かならＣの方が危険だと思う。

危険って言ってる奴がCでsegmentation faultとかの例外も書かないのが世の常

書くとろくなコードが生まれないからそのままでおk

例外が出るほうがおかしいでしょ

何の危険か知らんが、言語で判断するとか無いわ
そういう妄信的なブランド志向は、品質を見定めるのに邪魔になるぞ

はげどう

例外が出るほうがおかしいってI/Oで読み取りエラーとかブロッキングソケットが切断されたとか
どうすんだ？Cでお得意の無視？

例外でも何でも無いなあほうが

例外hookしないといけないの？

なんだ例外hook一度も書いたことない奴の煽りか、つまんね

自分のミスを例外のせいにしたいだけでしょ

>>878
このスレって応用利かない奴がいるんだよな
単に例外ってだけ書いて具体例を挙げないほうが良いみたいよ

これまでの流れ

Cが一番、JAVAは危険
↓
そんな奴に限って例外処理しない
↓
例外出るほうがおかしい
↓
じゃあ例外出たときは？
↓
自分のミスが原因

>>880
そんな想定外な事をしでかしてくれるのが、ユーザとか悪意ある者なんじゃね？

無限と有限の使い分けが中で出来てないからでしょ

単にケースバイケースって事じゃないか、馬鹿らしい

一般人の感覚で実装してますから、何があっても不思議じゃありませんから

>>883
> I/Oで読み取りエラーとか
仕様レベルでどうするか決めようね

> ブロッキングソケットが切断されたとか
c じゃなくても eof 扱いで, 想定外の通信終了処理をするのでは?

仕様ｗ

ここは住人のレベルのバラエティが広いんだな。
>>876-882 みたいな鋭い示唆に富んだ書き込みもあるが…
もうちょっと親切に書いてやろうよ。


>> どうすんだ？Cでお得意の無視？

sorryだなトホホ
オマエさんは（昔の俺みたいに）自分のバグを他人のせいにするタイプじゃ
ないか？気をつけなよ。（俺は>>887じゃないけどさ）

つづく

つづき

プログラム言語を本当に使えるアタマのいいひとは、オブジェクト指向や
例外機構も、整数エラーコードでのエラー処理も、単なる道具の一つとして
適材適所で使いこなすもんだぜ。例外だけがエラー処理じゃないよ。
（>>886 例えば、crt0（=mainの外）での例外処理仕様をわかったうえで
あえて書かなくて済むようにプロセス分割設計するひともいるんだぜ）



一般的には、IPネットワークの通信エラーって言うのは、割と頻繁に
（＋自分以外の機械のせいでも）起こりうるものなんだ。
最近の言語（C#とか）のAPIには通信エラーを例外で返すようなものがあって
その場合はしょうがないけど、頻繁に起こりうるエラーは整数戻り値
（エラーコード）で処理したほうが、速くてスマートなプログラムが書けるんだよ。

例外っていうのは元々は、自分の担当してる責任範囲では手に負えないエラーを
大外で捕らえるためのものなんだよ。
メイヤーの「契約に基づくプログラミング」手法のアナロジーで言うと、
「いろいろ手を尽くしたけど、どうしても契約を履行できないことを
（偉い人が頭を下げて）お客（呼び元）に謝るような場合」ってこと。

I/O で読み取りエラーとかブロッキングソケットが切断されたときってのは、
Cだと普通に戻り値でエラーが返ってきて、
それを自分のプログラムで（利用元がカスタマイズ可能な）回数リトライして、
それでもダメだったら例外で返すってのが、スマートだぜ。


例外がないって書き込みは、そういうこと（と俺は理解してるよ）。
エラー処理しないってことじゃない。

>> （利用元がカスタマイズ可能な）回数リトライ

って書いたけど、そのカスタマイズ方法っていうのは、
「関数呼び出しごとに呼び元がパラメータで指定」なんかじゃなくて、
「プログラム起動前にレジストリや環境変数に設定しておく。設定が
なければ事前に決めたデフォルト回数」
っていうレベルでいいんだぜ。


>>896が言ってる「仕様レベルで決めような」ってのはね...

リトライ回数なんかは、通信プロトコルを設計するような
設計工程（＝プログラミングより前）で、普通は決めるんだ。

やらしい話だが、
「リトライ回数は、顧客との仕様調整で決定。変えるなら、
プログラム変更して再コンパイル」にしておいて、
「簡単な仕様変更」として顧客から金を取れる、
新人教育のメシの種にするっていうこともあるんだよ。


俺なら、面倒だからカスタマイズ可能な項目としておいて、
客に勝手にしろ、といいたいけどな。

すまん >>894 だ

おーい、>901
>896-898な、ちょいくどいし長すぎるんだわ
スマートになるように3行ぐらいに要約しておいてくれ

すまんかった

>>883 >>886 >>889 はレベルが低い
もっと勉強しろ

これでいいか

最終的に>>892

ぱっと見は例外なんだけど、実際にはただの条件分岐　みたいな書き方って
うまい方法ないかな

プログラムの7割がエラー処理になっちゃうからあんまり美しくないというか

ぱっと身は条件分岐なんだけど, 実は例外ってのなら結構見掛けるが
逆は, あまりみたことない

うまいやつだと, 「実は例外」の部分さえ条件分岐しないことあるからなぁ

Java 辺りだと普通は条件分岐するようなところまで例外になるしな

通信プロトコル制御の場合は7割がエラー処理だから、
必然的にエラー処理を想定したロジックになるんだよね。
言い換えると(プログラミング言語の例外機構ではなく)
エラーを条件分岐で扱うロジックによって組立てることになる。
エラー処理を正常処理に持ち込む、あるいは正常とは
エラーの一種であるという発想による設計が求められる。

アプリケーションプログラムであれば、エラーが発生しても
メッセージを表示して続行するか、あるいはダイアログでユーザに
判断を委ねることが可能だから、例外機構に頼ることは間違いじゃない。
ただし、通信プロトコル制御はシステムソフトウェアの一種だから、
例外発生は、即システム停止(UNIXであればpanic、Winであればblue screen)、
あるいはアプリケーション全体の強制異常終了の場合にしか使い道が無い、
といっても間違いではないと思う。

そこで検査例外に意味がでてくるのですよ。

いや言ってみただけ。

panicとかブルースクリーンまで行かなくても、例外の使い道あるよ。
プロトコルデーモンだったら単にプロセス終了するため、でいいと思う。


C++で標準になった「テンプレートライブラリ」にはリンクリストやらが
用意されてて、要素追加のときにメモリブロックの追加確保が発生して
万一メモリ確保失敗するとbad alloc 例外を投げる仕様になってる。

C++ではユーザプログラムが拾ってない例外は、crt0がアボート処理
（メモリ全解放してプロセス終了）してくれる仕様になってる。

ということは、bad alloc例外は、いちいちプログラムで拾わずにcrt0に
まかせてプロセス終了し、あとはプロセスの生存監視をしてクラスタ切り替えする
仕組みに任せる、でOKってこと。
リンクリストの追加削除でいちいちメモリエラー拾うコードがなくなってすっきり。

最大数設定とか最大通信負荷のテストを結合テスト以降で必ずやるから、
本番環境でメモリ不足が発生することは基本的にありえないしね。


通信エラーなんか例外で扱うことじゃない、正常系の一部だってことで同意見。
JavaやC#のライブラリつくったやつは、例外の意義がわかってないアホ。

>>905
だからそれがなんとかならないかな という話なんだが。
仕方ないで済ますのは進化が無い

>>907
>プロトコルデーモンだったら単にプロセス終了するため、でいいと思う。

それが>>905の「アプリケーション全体の強制異常終了」に相当するのかな、と。

>JavaやC#のライブラリつくったやつは、例外の意義がわかってないアホ。

自分はUNIX Cしか知らない(C++/Java/C#は無知)のでコメントしづらいが、
もしシステムソフトウェア向けのライブラリに例外機構を前提とするAPIが存在するとしたら、
そんなライブラリを設計した奴らは「例外の意義がわかってないアホ」だ、という意見に同意。
おそらく周囲の開発環境は異なるけど、本質的な意味では同じ視野で問題を俯瞰している気がする。

>>908
>>905で書いたのは、システムソフトウェア(カーネル/デバドラ/低レベル通信ライブラリ)を
対象にして書いたし、もしそうであれば間違った(勘違いした)主張ではなかったはずだ、と思う。
ただし、今はネットワークプログラミングが(特殊な技能を持つ)システムプログラマだけでなく、
アプリケーションプログラマあるいはエンドユーザレベルでも一般化しつつある事も認める。
(それが、こんなスレがPart.26もの長寿スレとして継続している現実を意味していると思う。)

だから、そんな普通のプログラマが普通のアプリをネットワーク対応させようとした時に、
(>>908の言う)「なんとかならないか、仕方ないで済ますのは進化が無い」という意見も理解したい。

>>908

どうしてもやりたいならプログラムをデータ化すればできるんじゃないの。

構造体の第一変数がやるべきことで
第二変数がパラメータで
構造体の配列で「次にやるべきこと」を作って
エンジンに渡す
みたいなアレ。よくあるだろ。
GPU（グラフィック専用プロセッサ）とか
NPU（ネットワーク専用プロセッサ）に対する指示はそういう感じだよ。
細かいエラー処理は1レベル下に隠れる。


それか、「処理実行クラス」というか、ワーカクラスをつくって
そいつらを少し賢くする。作業指示するやつは、端的に指示するだけ。
そうすりゃ、「端的な指示」のソースから細かいエラー処理が消えてすっきり。
人間のチームにリーダーとメンバーがいるのと一緒よ。


ま、2つとも同じこと言ってるな。つまりメタレベルを１個上げれば
ソースの抽象度も1個あがる。
けど、ネットワークと関係ないコーディングテクの話じゃね？

まつもと？

あーすまん、そんで結局、
「例外投げるようなすっきり度、かつ分岐のような軽さで」
エラー処理したきゃ、

エラー処理選任のワーカを作れってこと。
第一線で処理しているワーカじゃなくて
エラー処理者にやるべき処理が回っていくような
プチフレームワークをつくればいいだけってこと。

クラス構成設計の基本テクな。

> エラー処理選任のワーカを作れってこと。
これが出てくる意味がわからん.

話の流れとしては, お前らの言う 「エラーも含めて通常処理にしてしまえ」 って,
ことじゃねぇの?
だとすると, エラー用のワーカってのは本末転倒じゃねぇの???
実際, ネットワークコード書くときにエラーなんてのは起って当たり前だし,
いちいち例外投げたり, 特別なワーカに投げたりするとコード汚くなるし...

うん。俺も「エラーも含めて通常処理にしてしまえ」派だけど
>>903 >>908 がしばらく考えこんでくれればそれでいい

うーんどうだろ
10年以上ネットワークいじってるけど答がでねぇ

エラーがでたら殺してしまえ - Erlang

ＶＣ＋＋＆ＷｉｎＳｏｃｋ２．２で、
ＨＴＴＰサーバーに接続してデータ取得する関数を作った

１　WinSock初期化
２　ＴＣＰソケット生成
３　サーバーに接続
４　GETでパラメータをＳＥＮＤ
５　shutdown(ＴＣＰソケット, SD_SEND)でデータ送信を閉じる
６　do{　受信バイト数=recv(ＴＣＰソケット,,）　}while（受信バイト>0）で０バイト受信するまで繰り返し
７　shutdown(ＴＣＰソケット,SD_BOTH)で送受信共に閉じる
８　ＴＣＰソケットを閉じる
９　WinSock解放

上記のようにコーディングして期待通りの動作を得ることができたが、
友人のＰＣでテストしてもらったところ、受信０バイトで処理が終了してしまう
ウイルスバスターが入った環境だったので、バスターのＦＷに認可してもらったがだめ
WindowsのＦＷを無効にしてもだめ　バスターのＦＷを無効にしてもだめ。
なのにウイルスバスター自体を終了すると通信できる
ウイルスバスターを終了しないでＦＷを有効にした状態でも
４と５の間にSleep(1000)とか入れるとちゃんと受信できる
根本的にＷｉｎＳｏｃｋの使い方を間違ってるんでしょうか？
どなたか詳しい方、ご教授願えませんか？

>>917

ｔｃｐは遅延有りOKなので
データー来ないからって即終了しちゃだめよ

５って必要なんだっけ？

>>918
えーと…最低一回recvするまでは
shutdown(ＴＣＰソケット, SD_SEND)
しないほうがいいってことでしょうか？

>>919
ワシの送信は終わったよって伝えないと
相手が「まだ通信してくるかも」と思って０を返してくれない
だからrecvでブロックしたまま固まってしまう
っていう認識なんだけど不要なの？