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

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

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

1 :デフォルトの名無しさん:2010/03/23(火) 20:31:49
主にソケットに関しての質疑応答スレッドです。

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/

2 :デフォルトの名無しさん:2010/03/23(火) 20:32:30
過去スレ:
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

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

4 :デフォルトの名無しさん:2010/03/23(火) 20:34:04
マスタリングTCP/IP RTP編
 http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
 http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/
Visual Basicではじめるネットワークプログラミング超入門
 http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/

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

6 :デフォルトの名無しさん:2010/03/23(火) 20:36:22
★プログラミング
C10K ヘヴィーロードサーバ
 http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
 http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
 http://www.whitefang.com/rin/
Java で packet capture
 http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
 http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
 http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
 http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
 http://X68000.q-e-d.net/~68user/net/

7 :デフォルトの名無しさん:2010/03/23(火) 20:42:11
★ツール類
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/

★プロトコル
TTCP
 http://www.sean.de/Solaris/ttcp.html
 http://www.kohala.com/start/ttcp.html
UDP Hole Punching
 http://homepage3.nifty.com/toremoro/p2p/firewall.html

★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm

8 :デフォルトの名無しさん:2010/03/23(火) 21:41:10
リンク切れぐらいは消せよ

9 :デフォルトの名無しさん:2010/03/23(火) 22:18:42
文句言うならお前が立てるか前スレで指摘しとけクソ野郎

10 :デフォルトの名無しさん:2010/03/23(火) 22:28:13
コピペしか出来ないコーダーは立てるなよ

11 :デフォルトの名無しさん:2010/03/23(火) 22:35:35
なら立てる前にちゃんと立てろ役立たず

12 :デフォルトの名無しさん:2010/03/23(火) 23:05:28
とりあえず>>1

13 :デフォルトの名無しさん:2010/03/24(水) 00:08:28
まずはプログラムやる前にtcp/ipの本読もうぜって感じだな。

14 :デフォルトの名無しさん:2010/03/24(水) 01:06:06
残り3レスしか無かったし、次スレ誘導くらいはしたかったから
いちいちリンク確認してる暇なかったんだわ
次スレではよろしく

15 :デフォルトの名無しさん:2010/03/24(水) 03:04:43
/   //   /   //    ______     /   //   /
 / //   /|   r'7\ ,.ヘ‐'"´iヾ、/\ニ''ー- 、.,   /    /
  /   / |  |::|ァ'⌒',ヽ:::ヽrヘ_,,.!-‐-'、二7-ァ'´|、__
`'ー-‐''"   ヽ、_'´  `| |:::::|'"       二.,_> ,.へ_
         /  //__// / / /      `ヽ7::/
 か っ も  |  / // メ,/_,,. /./ /|   i   Y   //
 ァ  て う.  |'´/ ∠. -‐'ァ'"´'`iヽ.// メ、,_ハ  ,  |〉
  |  約 ク  ヽ! O .|/。〈ハ、 rリ '´   ,ァ=;、`| ,ハ |、  /
  |  束 ソ   >  o  ゜,,´ ̄   .  ト i 〉.レ'i iヽ|ヽ、.,____
  |  し  ス  /   ハ | u   ,.--- 、  `' ゜o O/、.,___,,..-‐'"´
  |  た  レ  |  /  ハ,   /    〉 "从  ヽ!  /
  |  じ  は  |,.イ,.!-‐'-'、,ヘ. !、_   _,/ ,.イヘ. `  ヽ.
 ッ .ゃ .立   |/     ヽ!7>rァ''7´| / ',  〉`ヽ〉
 ! ! な  て   .',      `Y_,/、レ'ヘ/レ'  レ'
   い  .な    ヽ、_     !:::::ハiヽ.   //   /
   で   い   ./‐r'、.,_,.イ\/_」ヽ ',       /  /
   す      /    `/:::::::/ /,」:::iン、 /    /
          〈  ,,..-‐''"´ ̄ ̄77ー--、_\.,__  /
      ,.:'⌒ヽ ´         | |  , i |ノ   `ヾr-、


16 :デフォルトの名無しさん:2010/03/25(木) 03:32:11
これら俺のとこからリンク駄目だな。繋がるか?
★プログラミング
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

17 :デフォルトの名無しさん:2010/03/25(木) 03:58:19
http://www.sics.se/~adam/uip/
これはだいじょうぶ

18 :デフォルトの名無しさん:2010/03/27(土) 20:09:29
>>3の一番上の本だけじゃプログラムでの簡単なファイアウォールの作成はきついですか?

19 :デフォルトの名無しさん:2010/03/27(土) 20:28:02
そんな質問してる人には無理

20 :デフォルトの名無しさん:2010/03/27(土) 20:32:16
簡単だよ
http://ruffnex.oc.to/kenji/text/fire_a/

21 :デフォルトの名無しさん:2010/03/27(土) 20:51:40
>>19
個人の技術力うんぬんでなくその本でファイアウォールを作るだけの知識が
つくか聞いたんだす。
>>20
windows持ってないんです。。

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

22 :デフォルトの名無しさん:2010/03/28(日) 00:18:00
WSAAsyncSelectでイベント型のクライアント作ってるんだが
接続時のタイムアウトはどうやればいいの?
ioctlsocket + selectだとタイムアウトするまでメッセージ処理が止まっちゃうし

23 :デフォルトの名無しさん:2010/03/28(日) 02:28:42
ネットワーク以前に、もうちょっとプログラミングスキル高めたほうがいいよ。無茶過ぎる。

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匹目

24 :デフォルトの名無しさん:2010/04/02(金) 17:59:11
Linuxで、/proc/fdの下見るとソケット一覧が見られるけど
ここにちょっかいを出してネットワークを切断したいと思います。
いい方法はありますか?

25 :デフォルトの名無しさん:2010/04/03(土) 14:26:27
関係ないけど sudo rm -rf /proc/fd とかやるとどうなるのかな?


26 :デフォルトの名無しさん:2010/04/04(日) 04:20:30
>>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


27 :デフォルトの名無しさん:2010/04/07(水) 00:13:12
マスタリングTCP/IP RTP編
 http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/

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

28 :デフォルトの名無しさん:2010/04/07(水) 00:15:08
↑マスタリングTCP/IP 入門編の事です

29 :デフォルトの名無しさん:2010/04/07(水) 00:28:28
お前が理解できるかなんて、誰がわかるってんだよ

30 :デフォルトの名無しさん:2010/04/07(水) 00:41:28
切れすぎワロタw

31 :デフォルトの名無しさん:2010/04/07(水) 01:51:36
RecallToyotaProtocol

32 :デフォルトの名無しさん:2010/04/07(水) 02:55:21
最後はPriusだろ

33 :デフォルトの名無しさん:2010/04/08(木) 22:07:13
APIスレでスルーされたのでこっちに貼ります
リモートのIPアドレスからコンピューター名を得る方法ありますか?
自分も相手もWindows(XP以降)です
正しくはコンピューター名じゃなくてUNC名ですが


34 :デフォルトの名無しさん:2010/04/08(木) 22:19:34
2時間でスルーとかどんだけ自分勝手なんだって話だと思うが。

35 :デフォルトの名無しさん:2010/04/08(木) 22:44:23
ってかこのスレ全然建設的じゃないな。
教える気がないんだったら煽ってないで黙ってろよ。

36 :デフォルトの名無しさん:2010/04/08(木) 22:44:45
うるせえ

37 :デフォルトの名無しさん:2010/04/08(木) 23:14:21
ある。でも聞き方が気に入らないから取り方は教えない。

38 :デフォルトの名無しさん:2010/04/08(木) 23:21:38
お前にきいてねえよ。
他の奴、答えろ。

39 :デフォルトの名無しさん:2010/04/08(木) 23:23:13
ある。でも聞き方が気に入らないから、オレも取り方は教えない。

40 :デフォルトの名無しさん:2010/04/08(木) 23:23:42
やったことないけどWMIは使えないだろうか

41 :デフォルトの名無しさん:2010/04/09(金) 23:04:31
サーバで、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


42 :デフォルトの名無しさん:2010/04/09(金) 23:06:31
その仕様を作った奴にきいたら?
そいつはできるから仕様にしたんだろ

43 :デフォルトの名無しさん:2010/04/09(金) 23:14:13
客先は、同じ内容を他社にも発注しており、
他社システムは 100ms 内になっているため、
苦しんでおります・・・

44 :デフォルトの名無しさん:2010/04/09(金) 23:19:22
やりかた聞けよそいつに
客先にソースあんだろ?

45 :デフォルトの名無しさん:2010/04/09(金) 23:25:03
IISなら速いよ

46 :デフォルトの名無しさん:2010/04/09(金) 23:25:41
どーみてもボトルネックはDB操作。

47 :デフォルトの名無しさん:2010/04/10(土) 02:18:35
0.1秒って考えれば結構長時間にみえてくる

48 :デフォルトの名無しさん:2010/04/10(土) 03:59:46
FPSでpingが100以上だと致命的だな

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


50 :デフォルトの名無しさん:2010/04/10(土) 10:11:52
同期処理しなけりゃならないなら、NoSQL系の奴使うとか。
同期じゃなくて良いなら、要求をキューイングしておいて、別プロセスとかで処理すれば?

51 :デフォルトの名無しさん:2010/04/10(土) 10:22:16
コネクションプールしてないとか
まさかね

52 :デフォルトの名無しさん:2010/04/10(土) 10:34:46
他社は出来てるんだから遅い原因は>>41にあるという結論に至る。
>>51あるいはDBの設計が致命的にヘボい。

53 :デフォルトの名無しさん:2010/04/10(土) 10:36:30
プログラミングに工数かけるくらいなら、50万くらいで買えるそこそこ高速なDBサーバ提案しろよ。

54 :デフォルトの名無しさん:2010/04/10(土) 15:24:39
>>41
>サーバで、100クライアントからの要求を 100ms 毎に 1回受信
>(1クライアントは 10sec 毎に1回要求送信)
速攻クビにしたいレベル。

55 :デフォルトの名無しさん:2010/04/10(土) 15:34:59
とりあえずサーバがDBを兼ねているとして、検索するだけで更新が無いし、
検索用にスレッドを作っておいて検索内容を受信したら投げてseteventでもして起こす。
そういうのにすれば良さそう。

56 :デフォルトの名無しさん:2010/04/11(日) 02:39:31
他社で出来るなら、他社のシステム導入すればいいだけだしな。
遅いシステムしか組めない所はイラネ。

57 :デフォルトの名無しさん:2010/04/11(日) 09:10:58
サーバー、クライアントプログラミングを勉強しております。
サーバー側でacceptで停止している場合はどうしたらいいのでしょうか?
クライアント側を再起動すると直るのですが。
サーバー側でどうにかしたいのですが、accept内部で待ちに入ってしまったら
どうしようもないのですか?

58 :デフォルトの名無しさん:2010/04/11(日) 09:13:29
普通はacceptでブロックしないように、selectする。

59 :デフォルトの名無しさん:2010/04/11(日) 09:34:32
recvとsendのソケットをわざわざ別タスクにする意味ってありますか?
一つのソケットでsendとrecvやってはまずいでしょうか?

60 :デフォルトの名無しさん:2010/04/11(日) 14:22:30
どっちでも

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

61 :デフォルトの名無しさん:2010/04/11(日) 15:32:45
何故?

62 :デフォルトの名無しさん:2010/04/11(日) 16:10:31
別タスクって何?二つのソケットっていうこと?だとしたらそんな必要全然ない。

63 :デフォルトの名無しさん:2010/04/11(日) 16:34:50
>>62
二つのソケットつくるということです。タスクを別にして。
メリットってなんかあるのでしょうか?
設定の簡略化?

64 :デフォルトの名無しさん:2010/04/11(日) 17:04:20
二つのソケットってディスクリプタが別のソケットってこと?
それサーバ側とクライアント側でどう二つのコネクションを確立するつもり?

65 :デフォルトの名無しさん:2010/04/11(日) 17:16:44
UDPならコネクションいらないとおもいまして

66 :デフォルトの名無しさん:2010/04/11(日) 19:42:31
どっちでもいいと思うけど、なぜ頑なにひとつのソケットでやりたいのかの方が分からん

67 :デフォルトの名無しさん:2010/04/11(日) 19:57:59
二つのソケットつかってやろうとすると、なぜかうまくいかなかったので
ひとつでrawつかってるせいか。

68 :デフォルトの名無しさん:2010/04/11(日) 22:34:01
送信と受信を同じソケットでやるさい、送信と受信のバッファみたいなのは別なのでしょうか?

例えば、

while{
send
recv}

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

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

69 :デフォルトの名無しさん:2010/04/11(日) 22:40:32
UDPなんだかTCPなんだかはっきりしろ

70 :デフォルトの名無しさん:2010/04/11(日) 22:54:48
ごめんなさい。UDPです。

71 :デフォルトの名無しさん:2010/04/11(日) 22:56:16
疑問なんだけど、windosやmacが独自につかってるプロトコルを、
unixが受け取るにはどうしてるの?unixのtcp/ipでもないやつとか

72 :デフォルトの名無しさん:2010/04/11(日) 23:10:39
unixは盗人が標準装備だから
あとは判るな?

73 :デフォルトの名無しさん:2010/04/11(日) 23:56:41
すみません、詳しくお願い致します

74 :デフォルトの名無しさん:2010/04/12(月) 00:44:42
ただのUDPのデータと、DNSのデータってどうプロトコルの違いをみつけてるのでしょうか?

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

75 :デフォルトの名無しさん:2010/04/12(月) 01:01:35
同じUDPやTCPのデータであっても、セッション層やプロトコル層までいくデータでは、
recvの扱い方が違うのでしょうか?

76 :デフォルトの名無しさん:2010/04/12(月) 01:30:26
>>74,75
意味不明。まずは質問できる程度の知識をつけてから出直そう

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

78 :デフォルトの名無しさん:2010/04/12(月) 03:18:43
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);
}
}
続く

79 :デフォルトの名無しさん:2010/04/12(月) 03:20:43
私の考えではもしも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が消えています。なぜこのような動作をするのでしょうか。
長々とすみません。よろしくお願いします。

80 :デフォルトの名無しさん:2010/04/12(月) 03:23:23
fork

81 :デフォルトの名無しさん:2010/04/12(月) 07:28:40
recvってどこの層でデータをとってるのでしょうか?

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

82 :デフォルトの名無しさん:2010/04/12(月) 17:32:07
ソケットに対しての O_SYNC って何か意味を成すの?

83 :デフォルトの名無しさん:2010/04/12(月) 18:30:12
winsockについて質問です。よろしくお願いします。

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

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

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

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

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

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


84 :デフォルトの名無しさん:2010/04/12(月) 18:44:48
>>83
ちゃんと秒間60回吐かれ続けてるの?
ここでログとって時間調べた方がよくね?
あと、念のためマジで受信してるかパケットログ取ろうぜ

85 :デフォルトの名無しさん:2010/04/12(月) 18:51:19
>>84
はい、60回については通し番号やWindows時間とともに吐かせて確認したので、ループ自体は正常にまわっているようです。

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

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

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


86 :デフォルトの名無しさん:2010/04/12(月) 19:02:27
読みこんでないデータがあって通信バッファが空くまでまってるんじゃねーの?

87 :デフォルトの名無しさん:2010/04/12(月) 20:09:17
>>84
>send()してから、受信されるまでの間隔が5秒〜20秒くらいとものすごく遅延
これは明らかに何かが破綻しているね。

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

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


88 :デフォルトの名無しさん:2010/04/12(月) 21:02:30
UDPw

89 :87:2010/04/12(月) 22:26:20
アンカー間違ってた。>>83ね。

90 :デフォルトの名無しさん:2010/04/12(月) 23:26:19
ソケットのバッファって、どうなってますか?受信と送信用それぞれ別々?

91 :デフォルトの名無しさん:2010/04/12(月) 23:38:43
は?

92 :デフォルトの名無しさん:2010/04/12(月) 23:41:50
君が期待しているようなバッファはない

93 :デフォルトの名無しさん:2010/04/13(火) 00:02:54
>>90
一般的にはバッファというのはカーネル内での制限値の様な物。 必要があったら
配分して溜め、規定値を超えたら残りは状況に応じた処理をする。 受信側と送信側は
全く別。 

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

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

94 :デフォルトの名無しさん:2010/04/13(火) 00:02:54
>>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..

95 :デフォルトの名無しさん:2010/04/13(火) 01:37:01
>>80
pthreadじゃ出来ないんですか?
ソケットじゃなくてpthreadの方の問題ならスレチになってしまいますが。

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




97 :デフォルトの名無しさん:2010/04/13(火) 08:04:18
UDPであれ、TCPであれ、RAWであれ、1つのソケットで送受信ができるバッファが用意されるのでしょうか?

98 :デフォルトの名無しさん:2010/04/13(火) 08:22:19
1500バイトぐらいはあるんじゃね

99 :デフォルトの名無しさん:2010/04/13(火) 10:33:41
>>97
ソケットごとにな!

100 :デフォルトの名無しさん:2010/04/13(火) 13:12:04
ソケットにO_SYNCつけてみたけど、なにも変化なかった。
これって単に無視されてるだけ?

101 :デフォルトの名無しさん:2010/04/13(火) 14:34:05
変な質問繰り返してる奴って同一人物かな

102 :デフォルトの名無しさん:2010/04/13(火) 14:35:19
それ、2ch病の初期症状です

103 :デフォルトの名無しさん:2010/04/13(火) 16:01:54
>>101
>>82=>>100=俺です。
そんなに変な質問だったかな。

104 :デフォルトの名無しさん:2010/04/13(火) 18:34:22
とっても。

105 :デフォルトの名無しさん:2010/04/13(火) 21:26:50
どうやってソケットにO_SYNCつけたの?

106 :デフォルトの名無しさん:2010/04/13(火) 22:03:21
便乗質問させてください

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

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

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


107 :デフォルトの名無しさん:2010/04/14(水) 04:49:16
モゲラのクロスドメインって何?

108 :デフォルトの名無しさん:2010/04/14(水) 05:44:49
nagle意外に遅延させるものってあったかなぁ?

109 :デフォルトの名無しさん:2010/04/14(水) 06:33:42
匙をnagle

110 :デフォルトの名無しさん:2010/04/14(水) 09:27:00
>>108
ないんじゃね?200msもドンピシャだし。

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

112 :85:2010/04/14(水) 10:40:39
>>86-87
返事が遅れてすいません。

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

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

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

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

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

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

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

113 :デフォルトの名無しさん:2010/04/14(水) 11:18:44
>>111
TCP_QUICKACKじゃだめ?

114 :デフォルトの名無しさん:2010/04/14(水) 11:29:12
なんでSleepなんかしてんの?

115 :111:2010/04/14(水) 11:51:38
>>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を0に設定すると
SYN ACKは直ぐにACKされない。 しかし次にデータを送るとそのdatagramで
SYN ACKがACKされ、パケットが1個節約出来る。 

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

117 :106:2010/04/14(水) 21:13:40
>>111, 113, 116
ありがとうございます。

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

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


118 :デフォルトの名無しさん:2010/04/14(水) 21:16:35
>>117
そうです

119 :デフォルトの名無しさん:2010/04/14(水) 21:45:26
某のTCP/IPスタックがおバカだから

120 :106:2010/04/14(水) 23:17:13
すいません。
理由がわからないので、解説サイト等があれば、
教えて頂けないでしょうか?

121 :デフォルトの名無しさん:2010/04/15(木) 00:02:08
受信が小さくなったからこまめにack飛ぶようになったとかじゃないの?

122 :デフォルトの名無しさん:2010/04/15(木) 06:59:06
定期的に送受信をUDPでおこなっているのですが、
(他から絶えずデータが送られて来ている中で)
稀に送信が一瞬とまり、再開後の最初のパケットの中をみると特定の所だけデータがおかしくなっています。

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

123 :デフォルトの名無しさん:2010/04/15(木) 07:06:08
UDPだから

124 :デフォルトの名無しさん:2010/04/15(木) 07:06:15
UDPなら一瞬どころか何度止まっても文句言えんぞ

125 :デフォルトの名無しさん:2010/04/15(木) 07:09:36
NICのバッファが溢れて止まってるように見えるんだよ
UDPだからというわけではない

126 :デフォルトの名無しさん:2010/04/15(木) 07:10:57
>某のTCP/IPスタックがおバカだから

127 :デフォルトの名無しさん:2010/04/15(木) 07:13:31
linuxとかからping実行してみれ

128 :デフォルトの名無しさん:2010/04/15(木) 12:09:30
>>118って本当なの?

129 :デフォルトの名無しさん:2010/04/15(木) 18:02:08
>>128
本当です

130 :デフォルトの名無しさん:2010/04/15(木) 18:09:18
>>128
合ってるが、ACKはすぐに送信するかは判らない。
こちらの送信データが揃うまで待つかもしれない。
ただし届いた分のデータについてはアプリに渡してしまっても良い。
異常ケースとしてACKを送信しても相手に届かない場合もあるが、
それでもACKまでのデータは確定しているから、
その場合起こる再送信でもACK以前のデータは読み捨てられる。


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

132 :デフォルトの名無しさん:2010/04/15(木) 20:28:58
>>130
「届いた分のデータについてはアプリに渡してしまっても良い」
筈なのに、(というか渡すべきでしょ?)WinSockではACKを送信
した後になってはじめてアプリに渡すと>>118は言ってると思うのだが。
これは信じ難いので。。。
本当にそんな馬鹿な作りになってるのか試したいんだけど今試せない。。。

133 :デフォルトの名無しさん:2010/04/15(木) 21:05:30
ここは納期なんてないから
いつまでも待ってやるから
試してからまた来い

134 :デフォルトの名無しさん:2010/04/15(木) 23:20:53
>>132
それは前後しても構わないし、「後か先か」に意味がまったく無い。
ACKが相手に届くかどうかなんて知ったこっちゃないので。

135 :デフォルトの名無しさん:2010/04/15(木) 23:29:10
>>125
周期的に送ってるのに稀に数回分も連続してとまるのでしょうか?
また復帰するのも謎です
送受信のバッファが別なら受信ならともかく送信までいかないのが気にかかります

136 :デフォルトの名無しさん:2010/04/15(木) 23:33:37
基本がなってない気がする

137 :デフォルトの名無しさん:2010/04/15(木) 23:45:35
>>135
ネットワークプログラミングで重要なのは問題の切り分け。 結局wiresharkは使い始めたの?


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




139 :デフォルトの名無しさん:2010/04/15(木) 23:54:40
>>122
TCPを使いなはれ

140 :デフォルトの名無しさん:2010/04/16(金) 00:20:38
>>136
基本より深い問題なきがしないこともないですが、
UDPだとソケット自体がおかしくなることもあるってことでしょうか?


141 :デフォルトの名無しさん:2010/04/16(金) 00:21:08
>>140
ありまくりやがります

142 :デフォルトの名無しさん:2010/04/16(金) 07:17:58
ソケットが途中でこわれる原因は何でしょうか?

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

143 :デフォルトの名無しさん:2010/04/16(金) 08:05:26
ソケットは壊れねーよ。

144 :デフォルトの名無しさん:2010/04/16(金) 08:12:46
同じことを書こうとしたら先人が・・・

145 :デフォルトの名無しさん:2010/04/16(金) 08:31:23
自分のプログラミングのまずさをスタックがおかしいせいに
する癖がついている奴がいるな。ソケットが壊れるってw

146 :デフォルトの名無しさん:2010/04/16(金) 08:38:48
基本がわかってないから深い問題のような気がするだけなのに

147 :デフォルトの名無しさん:2010/04/16(金) 13:18:25
>>142
壊れるのはパケット

148 :デフォルトの名無しさん:2010/04/16(金) 20:47:59
ソケットが壊れるなんてちょっとないよね?と思ってたのに
>>141が壊れるよと言うもんだから

149 :デフォルトの名無しさん:2010/04/16(金) 20:58:55
最近打ち合わせでは分かり切ったことは飛ばして話を進めているのに
知識として持っててあたりまえのことを質問する馬鹿が増えた


150 :デフォルトの名無しさん:2010/04/16(金) 21:44:32
http://pc12.2ch.net/test/read.cgi/tech/1268699491/483
コピペ化する予定ですか?

151 :デフォルトの名無しさん:2010/04/16(金) 23:54:05
ソケットは本当に壊れることがないのだろうか

152 :デフォルトの名無しさん:2010/04/17(土) 01:18:25
>>97
それは実装依存
プロトコルに違反しないならなんでもOK



153 :デフォルトの名無しさん:2010/04/17(土) 06:14:38
>>151
普通はsocketが壊れるより先にまずpingが折れると思う

154 :デフォルトの名無しさん:2010/04/17(土) 07:21:38
pingがおれるとはどういうことでしょうか?

155 :デフォルトの名無しさん:2010/04/17(土) 07:38:46
CPUだろ
pinとpingをかけたか、素で間違えているか

156 :デフォルトの名無しさん:2010/04/17(土) 09:06:35
ネットワークプログラマならマイコンのIOピンを自分でON/OFFして
シリアル通信くらいしたことないとな

157 :デフォルトの名無しさん:2010/04/17(土) 09:10:06
TCP/IPじゃなくてシリアルですか

158 :デフォルトの名無しさん:2010/04/17(土) 17:25:14
その辺を混同して設計できるのがソケットプログラミングの強みだろ

159 :デフォルトの名無しさん:2010/04/18(日) 01:24:01
>>158
kwsk

160 :デフォルトの名無しさん:2010/04/18(日) 01:46:54
でもソケットのスレじゃなくてネットワークプログラミングのスレなんだよね

161 :デフォルトの名無しさん:2010/04/18(日) 02:04:23
惘網綱綳線縲織

162 :デフォルトの名無しさん:2010/04/18(日) 12:29:02
GET / POST で HTTP リクエストするけど
相手のサーバによっては拒否される?

163 :デフォルトの名無しさん:2010/04/18(日) 12:33:10
どっちかというと
クライアントによっては拒否される
が正しいと思う

164 :デフォルトの名無しさん:2010/04/21(水) 06:24:24
受信割り込みを一時的に受付ないようにするにはどうすればよいのでしょうか?

165 :デフォルトの名無しさん:2010/04/21(水) 14:01:09
AcceptExなどのmswsock.dllに実装されている関数を、
WSAIoctlで取得した関数ポインタで呼び出すことが推奨されていると以下のページで書かれています。
ttp://eternalwindows.jp/network/winsock/winsock06c.html

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

166 :デフォルトの名無しさん:2010/04/21(水) 14:16:05
>>165
差し換わるかもしれんじゃん。

167 :デフォルトの名無しさん:2010/04/21(水) 14:30:55
>>165
レス有り難うございます。
差し換わるというのは、コンパイル時に直接記述されたAcceptExのアドレスが、
mswsock.dllの変更やバージョン違いによってアドレスが変わってしまうという解釈で宜しいのでしょうか?
dllに関しての知識が不足してるので、見当違いでしたら申し訳無いです。

168 :デフォルトの名無しさん:2010/04/21(水) 14:32:26
すいません、レス番ミスです。
>>167 >>166


169 :デフォルトの名無しさん:2010/04/21(水) 14:48:10
>>167
mswsock.dllじゃなくなるかも。という事だろう。

170 :デフォルトの名無しさん:2010/04/21(水) 15:18:30
>>169
そういうことでしたか。
教えてくださった方どうも有り難うございました。

171 :デフォルトの名無しさん:2010/04/21(水) 19:56:30
recvfromって受信割り込みで動くのでしょうか?
デバイスドライバへの割り込みがきたあとに、recvfromをすることによって
データをとれるのでしょうか?
デバイスドライバへの割り込みを禁止してしまうと、データはrecvfromでとれないということ?

172 :デフォルトの名無しさん:2010/04/21(水) 20:01:01
http://pc12.2ch.net/test/read.cgi/tech/1205795434/780

173 :デフォルトの名無しさん:2010/04/24(土) 02:39:32
winsockで、アクセプトしてるネットワークカードの
127.0.0.1でないIPを取得する方法はありますか?


174 :デフォルトの名無しさん:2010/04/24(土) 02:52:22
>>173
アクセプトしているなら接続元のIPを取得できる

175 :デフォルトの名無しさん:2010/04/24(土) 11:29:51
>>173
getsockname

176 :デフォルトの名無しさん:2010/04/24(土) 12:32:45
IPってゆうな。クズ。

177 :デフォルトの名無しさん:2010/04/24(土) 16:44:22
>>176
っ□

178 :デフォルトの名無しさん:2010/04/24(土) 20:24:54
IPが駄目ならXPで、それでも駄目なら申し訳ないが:Pになる

179 :デフォルトの名無しさん:2010/04/29(木) 20:51:59
ゆうな、なんて書くなよ恥ずかしい

180 :デフォルトの名無しさん:2010/04/30(金) 16:02:08
ゆうなってゆうよ
はずかしがったらいかん

181 :デフォルトの名無しさん:2010/04/30(金) 19:33:45
Windows XPのTCPをオリジナルのTCPに変更したいのだが、
WinSockとかWinPcapとか使えば可能でしょうか?

182 :デフォルトの名無しさん:2010/04/30(金) 19:47:31
は?

183 : ◆0uxK91AxII :2010/04/30(金) 19:50:16
不可能。

184 :デフォルトの名無しさん:2010/04/30(金) 20:30:06
可能。

185 :181:2010/04/30(金) 21:25:22
Winsockの呼び出しをフックするか、
winsock.dllのラッパーを作れば良さそうですね。
ありがとうございました。

186 :デフォルトの名無しさん:2010/04/30(金) 21:26:57
ネトゲに割り込むのかな?

187 :デフォルトの名無しさん:2010/05/02(日) 10:25:54
質問です。

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

188 :デフォルトの名無しさん:2010/05/02(日) 10:41:13
http://checkip.dyndns.org/

189 :デフォルトの名無しさん:2010/05/02(日) 11:52:21
>>187
一般的には、UPnPを使うことになると思います。
winsockでゴリゴリ書いてももちろんかまわないのですが、COMインターフェースが
用意されているので使ってみてはどうでしょうか?

190 :デフォルトの名無しさん:2010/05/03(月) 09:25:03
NAT越しに通信してるときに
NAT後に利用している送信元ポート番号を知る方法ない?
通信相手に教えてもらう以外で。
あったら教えてください。

191 :デフォルトの名無しさん:2010/05/03(月) 10:03:19
ない、プロトコルを学ぶべき

192 :デフォルトの名無しさん:2010/05/03(月) 10:11:05
>>191
プロトコルから外れた標準外の方法でもいいんだけど。
まぁ確かにライブラリを使うってだけの話じゃないから、
難しいってのはわかるよ。

193 :デフォルトの名無しさん:2010/05/03(月) 10:46:14
横からですが、それできちゃったらNATの意味ないんじゃ・・・・
クラッカーとかはどうか知らんけど・・

194 :デフォルトの名無しさん:2010/05/03(月) 12:30:20
NATの内側同士でP2Pするソフトがあるから
それのソース見て勉強しなさい

195 :デフォルトの名無しさん:2010/05/03(月) 20:48:35
Winsock2の質問ですが、
ソケットエラーが返ってきた場合でもclosesocket()は必要でしたっけ?

196 :デフォルトの名無しさん:2010/05/03(月) 21:23:21
>>195
ソケット作成時以外なら要るだろう。

197 :デフォルトの名無しさん:2010/05/04(火) 02:28:16
>>196
ありがとうございました。

198 :デフォルトの名無しさん:2010/05/04(火) 07:57:06
>>193
知られちゃダメなNATの意味ってなんだよ。UPnPなんか許せない死ねという主張か?

199 :デフォルトの名無しさん:2010/05/04(火) 21:21:47
>>190
NATトラバーサルとかそういうこと?

200 :デフォルトの名無しさん:2010/05/06(木) 19:01:45
ネットワークについての質問です。
皆さんの力をお貸しください。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1440449509

201 :デフォルトの名無しさん:2010/05/06(木) 19:28:45
>>200
普通に共有フォルダでいいだろw

202 :デフォルトの名無しさん:2010/05/06(木) 21:01:01
>パソコン部の高校での文化祭で展示したいものがあります。
>それが、パソコン2台を接続してハードディスクなどを共有することです。

どこの国の人だよ

203 :デフォルトの名無しさん:2010/05/06(木) 21:57:30
>>202
パソコンの中、つまり仮想世界なんです

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


204 :デフォルトの名無しさん:2010/05/06(木) 22:25:18
一部といわず、全部仮想世界の出来事にすればいい
死んでるように見えますが、仮想世界では生きてます

205 :デフォルトの名無しさん:2010/05/06(木) 22:40:13
matrixの世界だな

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

206 :デフォルトの名無しさん:2010/05/06(木) 22:40:17
今度はどこの漫画なんだろう。
最近チェックしてないからよく分からん。

207 :デフォルトの名無しさん:2010/05/07(金) 00:20:08
                     _                 (  信.  信   余   )
                      ,r'⌒  `ヽ             )  じ  じ  は  (
                  ( (  ,.  ┴─ .         (   た   ぬ      丿
                     ゝ  ´   /     \        )  く           (
                       「     厂ッヘ ̄\ ',      (    な         )
                  リ    ./  ,==≧v ,ィ}       ノ   い          /
                   /    {  〃   j 「`'}      \             ノ
                     /    .|  r--、_ イ }       ゝ─っ  .-─'′
                    ,イ      | 彳 ̄` ‐.マ}ノ        --==彡 ' 
               r'´ :l  \  .| {_,,_  //
           _/   ゝ.   \\    `´/
        / ̄            ミ≧rrrイ
       /                 ヾツ\
      /         \                \
    /           \                ノ. \
. /        .-‐===キミ、_____∠彡=≧
. '       / ̄ヽ         ∨://///V///// /  ̄\
       /    |  / ̄ ̄ ̄∨////////// /    \
     /      |  / r──-く^V://///// //      ヘ

208 :デフォルトの名無しさん:2010/05/07(金) 10:40:10
素朴な疑問なのですが、Winsockの
WSAAsync
は何の略なのでしょうか?

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

209 :デフォルトの名無しさん:2010/05/07(金) 10:51:59
WSA: Windows Sockets API

210 :デフォルトの名無しさん:2010/05/07(金) 10:54:07
WinSockApiASynchronous かな

211 :デフォルトの名無しさん:2010/05/07(金) 10:55:57
WinSockAPI Async

212 :デフォルトの名無しさん:2010/05/07(金) 13:07:02
ASync のAは一体・・・

213 :デフォルトの名無しさん:2010/05/07(金) 13:22:25
アシンクロナスだろ
非同期っつー意味

214 :デフォルトの名無しさん:2010/05/07(金) 13:50:43
おお、Asynchronous で非同期って意味か

215 :デフォルトの名無しさん:2010/05/07(金) 13:59:30
うわあ、ネタじゃ無かったのか。

216 :デフォルトの名無しさん:2010/05/07(金) 14:21:14
Sを大文字にしてる香具師は馬鹿

217 :デフォルトの名無しさん:2010/05/07(金) 14:22:20
>>216とか>>216とか>>216とか
の事か?

218 :デフォルトの名無しさん:2010/05/07(金) 15:18:27
質問よろしいでしょうか
gethostbynameは即座に処理が返ってくるとは限らないので、なるべく
WSAAsyncGetHostByName を使った方が良い。

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

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

219 :デフォルトの名無しさん:2010/05/07(金) 15:32:39
壊れた(Timeout長めにポートフィルタされた)DNSに登録されているドメインのFQDNを指定する

220 :デフォルトの名無しさん:2010/05/07(金) 15:38:35
>>218
存在しないLAN外のアドレスを指定するといいよ

221 :デフォルトの名無しさん:2010/05/07(金) 15:47:37
>>219
となると、自前でDNSサーバーを立てなければなりませんね。
仕組みは知っているものの、気軽に立てられるものなのかなどはサッパリです。今ぐぐって勉強し始めました

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

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

222 :デフォルトの名無しさん:2010/05/07(金) 15:49:51
>>218
実験するPCのファイアウォール設定でTCP53行きパケットを破棄しておいて実行する
(REJECTじゃなくてDROPね)


223 :デフォルトの名無しさん:2010/05/07(金) 15:54:22
LAN内の存在しないアドレスをネームサーバとして設定する。

224 :デフォルトの名無しさん:2010/05/07(金) 15:58:49
>>223
10秒くらい稼げるね

225 :デフォルトの名無しさん:2010/05/07(金) 16:08:34
>>222-224
アイデアありがとうございます。

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

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

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

この状態で実験。

226 :デフォルトの名無しさん:2010/05/07(金) 16:24:44
やっぱさ、任意の通信障害を起こせるHUBってほしいよね。

227 :デフォルトの名無しさん:2010/05/07(金) 17:02:57
>>226
dummynet

228 :デフォルトの名無しさん:2010/05/07(金) 17:06:08
linuxならnetem、freebsdならaltq使えば、大抵のエラーは起こせるだろ。
fcs壊すようなL2エラーとか、ワイヤレート欲しいとかなら専用ハードになるけど。


229 :デフォルトの名無しさん:2010/05/07(金) 17:47:27
通信遅延とかそういう現象も全部試験したいなら、GtrcNETという装置があるぞ

230 :デフォルトの名無しさん:2010/05/07(金) 17:59:43
>>229
netemやdummynetは遅延出来るよ.

231 :デフォルトの名無しさん:2010/05/07(金) 18:31:39
長いLANケーブル使えばいいじゃん

232 :デフォルトの名無しさん:2010/05/07(金) 18:33:33
箱ごと何巻も繋いでるのを見たことがあるな

233 :デフォルトの名無しさん:2010/05/07(金) 18:41:39
まずブラジルに親戚を作ってだな・・・

234 :デフォルトの名無しさん:2010/05/07(金) 18:44:15
意外と近くて遠い国は北朝鮮とか

235 :デフォルトの名無しさん:2010/05/07(金) 20:56:51
相談よろしいでしょうか。

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

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

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

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


236 :デフォルトの名無しさん:2010/05/07(金) 22:28:58
別スレッドで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.

237 :デフォルトの名無しさん:2010/05/08(土) 23:42:08
サーバー側のWinsockプログラムで質問です。
特定のIPからのアクセスを「成立させずに却下する」ことはできないでしょうか?

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

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

238 :デフォルトの名無しさん:2010/05/08(土) 23:46:37
そんなもんスイッチにやらせりゃいいじゃん

239 :デフォルトの名無しさん:2010/05/08(土) 23:55:42
スイッチ?とはなんでしょう?

240 :デフォルトの名無しさん:2010/05/09(日) 00:00:52
ははは
ご冗談を

241 :デフォルトの名無しさん:2010/05/09(日) 00:12:23
netsh

242 :デフォルトの名無しさん:2010/05/09(日) 00:28:39
>>239
ルーター、サーバーのファイアウォールでしっしっ

243 :デフォルトの名無しさん:2010/05/09(日) 00:34:06
アプリケーションでやるのが目的となります。
何か方法があれば教えていただけますでしょうか。

244 :デフォルトの名無しさん:2010/05/09(日) 00:38:07
FWもアプリケーション

245 :デフォルトの名無しさん:2010/05/09(日) 00:55:14
すげえ揚げ足取り

246 :デフォルトの名無しさん:2010/05/09(日) 03:00:09
IPってゆうな。クズ。

247 :デフォルトの名無しさん:2010/05/09(日) 05:25:01
>>243
acceptする前にackを返すので無理です。
SYN FLOODがなぜ未だに有効な攻撃手段なのかを考えればわかると思いますが、
アプリ側でやれる事といえばせいぜいBACKLOG数を調整するくらいです。

248 :デフォルトの名無しさん:2010/05/09(日) 09:02:42
何度このリンクを貼ればいいのか
http://ruffnex.oc.to/kenji/text/fire_a/

249 :デフォルトの名無しさん:2010/05/09(日) 13:01:35
何回目?

250 :デフォルトの名無しさん:2010/05/09(日) 14:06:19
accept拒否はWSAAcceptのlpfnConditionを使えば出来るんじゃないの?

251 :デフォルトの名無しさん:2010/05/09(日) 14:30:52
>>237
可能。winsock限定になるが。
MSDNで「SO_CONDITIONAL_ACCEPT」と「WSAAccept」を参照すべし。

252 :デフォルトの名無しさん:2010/05/09(日) 15:43:20
>>249
もう二度目だよ
いい加減にしてほしい

253 :デフォルトの名無しさん:2010/05/09(日) 17:37:11
>>248
UNIX版も作って!

254 :デフォルトの名無しさん:2010/05/09(日) 22:22:10
>250-251
ありがとうございました。
無事できました。
しかしこれ、情報少ないですね。
気になる点としては

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

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

255 :デフォルトの名無しさん:2010/05/10(月) 15:25:50
>>254
KBの328264についてはXP Service Pack 2で修正済みとあるよ。
ただそれでもSO_CONDITIONAL_ACCEPTを使わない場合と比較すると
一定時間内に受け付け可能な接続数とかは低下するだろうけど。

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

256 :デフォルトの名無しさん:2010/05/10(月) 17:30:07
>>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が2〜3回反応します。
サーバーとクライアントは同PC上で動作させ、localhostへ向かってconnectさせています。

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

257 :デフォルトの名無しさん:2010/05/10(月) 17:44:40
反応というのはprintf("%d\n", user);の出力があるという事か?
その時のuserの値は?

258 :デフォルトの名無しさん:2010/05/10(月) 18:06:34
>>257
はい、printfが2〜3回反応します。ほとんどの場合3回です。
値は -1なのでINVALID_SOCKETです。

259 :デフォルトの名無しさん:2010/05/10(月) 22:59:12
>>256
調べたけどWinsockではSYNに対するRSTはクライアント側で
無視されるみたいですね。>>248の方が良いかも。


260 :デフォルトの名無しさん:2010/05/10(月) 23:02:27
まあ>>248でもクライアントは3回SYN出すわけだけど。

261 :デフォルトの名無しさん:2010/05/11(火) 02:35:32
>>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

262 :デフォルトの名無しさん:2010/05/11(火) 09:16:25
とりあえず、正常な動作だということで安心しました
細かくありがとうございました。

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

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

263 :デフォルトの名無しさん:2010/05/11(火) 10:35:07
こういう質問者ばかりだと、答える側も嬉しいのう

264 :デフォルトの名無しさん:2010/05/11(火) 17:43:34
すいません、また迷い込んでしまったもので相談させてください。
262です。

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

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

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

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

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

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

265 :デフォルトの名無しさん:2010/05/11(火) 19:57:30
あらかじめ特定のIPがリストアップされてるなら
フィルタしてしまうのが一番良いと思うんだが

266 :デフォルトの名無しさん:2010/05/11(火) 20:09:35
やはり>>248だな

267 :デフォルトの名無しさん:2010/05/11(火) 21:07:00
IPってゆうな
これでいいですか? >いつもの人

268 :デフォルトの名無しさん:2010/05/11(火) 22:07:26
文脈で判るものにいちいち文句たれるのは異常者

269 :デフォルトの名無しさん:2010/05/11(火) 22:50:08
ホームページじゃないのにホームページとかな

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

271 :デフォルトの名無しさん:2010/05/11(火) 23:34:52
IPと言うなと言ってるやつが何を意図してるのかさっぱりわからんので
解説よろしこ

272 :デフォルトの名無しさん:2010/05/11(火) 23:41:42
IPはインターネットプロトコル。
IPアドレスと言え。

273 :デフォルトの名無しさん:2010/05/11(火) 23:42:00
IPってゆうな。クズ。

274 :デフォルトの名無しさん:2010/05/11(火) 23:52:08
      ,―ヽ_(((((_、―
   ,/  ノ       ヽ  ~\
  /   ノ   IPA    ヽ   ~\
/   ノ           ヽ、  `ヽ
|    ノ / ̄\   / ̄~ヽ ヽ    i
|   ノ              |  ノ
\  |  <●>  <●>  (  )
 \ |      | |       i /
    |      /  ヽ       レ
   i     (●_●)      /  
    i、    ,-――-、   ・ /
    i、  <(EEEEE)> ∵/    どういたしまして
      i、  \   ./  /
       \   ーー   ,ノ       
  ,,.....イ.ヽヽ、ー-―一ノ゙-、.
  :   |  '; \_____ ノ.| ヽ i
      |  \/゙(__)\,|  i |

275 :デフォルトの名無しさん:2010/05/12(水) 00:29:41
>>272
なるほど。
友達とか仕事やらで
関わりあいたくないタイプだということは分かった。

276 :デフォルトの名無しさん:2010/05/12(水) 09:02:05
>>265
*.dion.jp とかでNG設定する機能を作りたいものでして

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

277 :デフォルトの名無しさん:2010/05/12(水) 11:03:42
>>276
危険というかCF_DEFER使った場合のシステムの動きがよく分からないから。
>>264
>しかし、次のWSAAcceptでは、先ほどCF_DEFERを返したはずの接続要求をまた取得してしまいました。
>2つ目の接続要求が来ている状態にも関わらずです。
ということは一旦CF_DEFERを返したらその接続要求にCF_ACCEPTかCF_REJECT
を返すまで他の接続は受け付けられないようになっているんじゃないのか?
と思えるし、その状態で1つ目の相手がリトライした場合どうなるのか?とか。

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

278 :デフォルトの名無しさん:2010/05/12(水) 11:39:34
知っているわけでも、アドバイスできるわけでもないなら、質問者や場を混乱させるなよ・・・

279 :デフォルトの名無しさん:2010/05/12(水) 13:04:44
解決法は知っているがIPと呼ぶ質問者には教えない事にしている。

280 :デフォルトの名無しさん:2010/05/12(水) 16:37:34
>>279
よろしくお願いします。

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

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

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

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

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

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

281 :デフォルトの名無しさん:2010/05/12(水) 16:41:26
unixならそういう場合preforkしてacceptを並列で待てば終わりなんだが、
windowsはスレッドorプロセス毎に並列でacceptってできないんだっけ?

282 :デフォルトの名無しさん:2010/05/12(水) 17:00:25
>>281
そもそもunixならaccept以前にSYN/ACK返す方法(一旦受け入れる)しかないでしょ。

283 :デフォルトの名無しさん:2010/05/12(水) 17:03:21
>>282
方法が無いわけではない

284 :デフォルトの名無しさん:2010/05/12(水) 19:02:26
またおまえか

285 :デフォルトの名無しさん:2010/05/12(水) 19:12:22
>>280
IPアドレスと正しく呼んだので教えよう。

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


286 :デフォルトの名無しさん:2010/05/12(水) 20:41:06
>>285
試してみましたが、スレッド側で「CF_REJECTかCF_ACCEPTを返すWSAAccept」が制御を返さない限り、
select()で「次のコネクト要求来たよ」という反応が出ないようです。

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

287 :デフォルトの名無しさん:2010/05/12(水) 21:05:09
やっぱりか。

288 :デフォルトの名無しさん:2010/05/13(木) 02:30:26
XpだとCF_REJECTしても、REFUSEではなく接続後即切断。

289 :デフォルトの名無しさん:2010/05/13(木) 10:16:11
>>286
そういう挙動なら、SOCK_RAWで監視するスレッドで先読みしておけば少しは改善する。
時間のかかるのが先に到着してしまったなら、回避出来ないけど。

>>288は嘘だった。

290 :デフォルトの名無しさん:2010/05/13(木) 10:42:44
時間のかかるのが来た時に、それの影響を受けないようにしたいってのが質問の肝なんじゃね?

291 :デフォルトの名無しさん:2010/05/13(木) 13:21:45
プロトコルスタックレベルの待ち行列のようだから、プロセス分けてもダメだろうな。

292 :デフォルトの名無しさん:2010/05/16(日) 21:11:09
結局のところ、コネクト許可してからはじくしかなさそうだね

293 :デフォルトの名無しさん:2010/05/19(水) 21:47:01
linux上で、HTTP通信の内容をすべてチェックしてパケットを通過させる、させないを制御したいんですが
なにを使って実装するのが一番簡単ですか?

294 :デフォルトの名無しさん:2010/05/19(水) 21:53:35
例をあげよ

295 :293:2010/05/19(水) 22:15:37
例えば、URLに特定の文字列が含まれるリクエストがきた場合は、
そのパケットを破棄して、かわりにエラーを返すといったことをしたいです。

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


296 :デフォルトの名無しさん:2010/05/19(水) 22:27:13
>>295
ローカルプロキシとは違うの?

297 :293:2010/05/19(水) 23:15:50
やりたいことは似ていますが、プロキシを間に挟むことによる制限が都合よくないので
どちらかというとiptablesみたいなものが近いです。

298 :デフォルトの名無しさん:2010/05/19(水) 23:24:34
例をあげろって言ってんだろボケ

299 :デフォルトの名無しさん:2010/05/19(水) 23:55:33
>>297
プロキシを間に挟むことによる制限って例えばなに?

300 :デフォルトの名無しさん:2010/05/20(木) 05:14:54
sctpって使ってる? ふと気がつくと大抵のホストに実装がのっている感じ。 
ためしに簡単なechoサーバー/クライアントの組み合わせでソケットの生成を
socket(AF_INET, SOCK_STREAM,IPPROTO_SCTP)に変えただけでLinux上で
普通に動いた。

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

301 :デフォルトの名無しさん:2010/05/20(木) 08:20:26
>>297
http://www.linux.or.jp/JF/JFdocs/TransparentProxy.html

302 :デフォルトの名無しさん:2010/05/20(木) 18:06:43
>>300
現状TCP/UDPでインフラが作られちゃってるから、
SCTPで動くものは非常にすくない。
使ってるのは大抵その人のオナニー。

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

303 :デフォルトの名無しさん:2010/05/20(木) 20:33:32
SCTPの特徴を三行で教えてくだしあ


304 :デフォルトの名無しさん:2010/05/20(木) 20:57:41
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 :デフォルトの名無しさん:2010/05/20(木) 23:16:07
ルーターは対応してるの?

306 :デフォルトの名無しさん:2010/05/20(木) 23:39:42
>>305
第3層プロトコルだから通過する限りは別にIPだから必要なし。 ファイアーウォールや
帯域管理なんかはどうだろうね。 

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

307 :デフォルトの名無しさん:2010/05/20(木) 23:47:57
>>302
> SCTPで動くものは非常にすくない。

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

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

308 :デフォルトの名無しさん:2010/05/21(金) 11:45:18
基礎的なところで相談させてください。
長文ですいません。

今勉強として、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を使うとともに、別スレッドでユーザーたちを監視するような形にすると、今度はスレッド間の排他処理で実装が少し複雑になります。

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

309 :デフォルトの名無しさん:2010/05/21(金) 13:24:20
タイマー抜きでポーリングするとCPUパワーを食いつぶすからするなってことじゃない?
チャットならミリ秒で応答する必要もないので数百ミリ秒程度間隔をあけてポーリングすれば大丈夫だと思うけど


310 :デフォルトの名無しさん:2010/05/21(金) 13:59:08
>>309
すいません、確かにポーリングが怒られているのは
「recvが、期待したデータ量をよこすまで延々ポーリング」
のような、それブロッキングでやれよといった内容についてのようです。

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

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

311 :デフォルトの名無しさん:2010/05/21(金) 14:06:32
非ブロッキングソケットは御法度だろ
WSAAsync使え


312 :デフォルトの名無しさん:2010/05/21(金) 14:18:28
APIのほうで非推奨とかにされてないなら
あとはもう宗教だろw


313 :デフォルトの名無しさん:2010/05/21(金) 14:26:20
動けばよい

314 :デフォルトの名無しさん:2010/05/21(金) 14:27:47
非ブロッキングがご法度って、何で?
非ブロッキング+select()って、ブロッキングの次にポータブルだから
何だかんだで良く使われてると思うけど

315 :デフォルトの名無しさん:2010/05/21(金) 14:28:25
おれselectでグルグルしてるけど
今まで苦情言われたこと無いよ

316 :デフォルトの名無しさん:2010/05/21(金) 14:41:33
サーバーのメインループでrecv処理なんてしたら、
誰かが高速で大量のデータ送ってきた際に、その処理に時間食われて
肝心のメインループが処理落ちしちまうだろ

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

317 :デフォルトの名無しさん:2010/05/21(金) 15:01:13
>>316
効率上の話か
効率が再重要ならWSAAsyncSelect()も勿論ダメで
IOCP + Overlapped I/Oしかないんじゃね

318 :デフォルトの名無しさん:2010/05/21(金) 15:04:55
>>317
極論すぎるんだよお前は

319 :デフォルトの名無しさん:2010/05/21(金) 15:29:35
>>308
その遅延機能実装するなら、同じユーザの発言なら遅延するような
アダプタを出力前にかませればよいのであって。ソケットからどう
読むかなんてどうでも良いのでは?

320 :デフォルトの名無しさん:2010/05/21(金) 15:37:43
>>318
いや、裏タスクは当然裏でやるとして
select, accept, recvを同一のスレッドで走らせると処理落ちすぎるぐらいの
サーバなんだろ?
IOCPしか無いと思うけど

321 :デフォルトの名無しさん:2010/05/21(金) 15:40:51
CPUが100%から落ちなくてCPUクーラーがぶんまわってウゼエ
ってソフトがあった

322 :デフォルトの名無しさん:2010/05/21(金) 15:55:50
WMPですね

323 :デフォルトの名無しさん:2010/05/21(金) 15:57:44
要はWinSock(Windowsのソケット実装)がヘボいんだよ。
まあBSDモドキがMSの目的だったからな。
Windowsでまともなネットワークプログラミングをしたかったら、
モドキなWinSockじゃなくMS謹製のWindows APIを使えってことだ。

324 :デフォルトの名無しさん:2010/05/21(金) 17:29:21
>>319が意味不明なんだが、誰か説明してくれ

325 :デフォルトの名無しさん:2010/05/21(金) 18:22:50
>>308
下手の考え休むに似たり
case毎に適した方法でやるのがいい、一般的な解なんてない

326 :デフォルトの名無しさん:2010/05/22(土) 07:49:22
>>316
まあいいんじゃないの?

327 :デフォルトの名無しさん:2010/05/22(土) 14:08:35
>>323
WinSockでも、WinSock上でも無いNetwork APIって何?

328 :デフォルトの名無しさん:2010/05/22(土) 14:58:14
>>327
こまかいな、意味分かるんだからいいだろ。
お前友達いないだろ?

329 :デフォルトの名無しさん:2010/05/22(土) 15:00:01
>>328
プログラマって細かい性格じゃないとやっていけないと思うので、
これは職業病だと思って放置すれば良いと思いますよ。

330 :デフォルトの名無しさん:2010/05/22(土) 15:02:32
いや、328はよくない
絶対に許さない

331 :デフォルトの名無しさん:2010/05/22(土) 15:04:19
>>328
いや、俺も全く意味が分からないぞ

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

一体何が言いたいの?

332 :デフォルトの名無しさん:2010/05/22(土) 15:50:56
>>328
「Windowsでまともなネットワークプログラミングが出来る
WinsockじゃないMS謹製のWindows API」について是非教えて頂きたい。
あなたは凄く詳しいようだから。

333 :デフォルトの名無しさん:2010/05/22(土) 16:51:25
311=316=318=323=328
なのかなあ

334 :デフォルトの名無しさん:2010/05/22(土) 18:51:07
winsockじゃないTCP/IPのAPIってあんの?
おせ〜て


335 :デフォルトの名無しさん:2010/05/22(土) 18:51:24
nagleアルゴリズムについての質問です。
これを無効にした場合、順序性は保たれるのでしょうか?

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

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

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

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

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

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

336 :デフォルトの名無しさん:2010/05/22(土) 19:02:10
>>335
順序とnagleとは関係ないだろう。

337 :デフォルトの名無しさん:2010/05/22(土) 19:06:28
>>335
そのACK ('B')なんて出ないよ。
nagleアルゴリズム無効にしたからって順序性が崩れるわけがありません。
教科書読み直してガンバレ


338 :デフォルトの名無しさん:2010/05/22(土) 19:14:50
>>336,337
ありがとうございます。
どうも覚え違いのようですね。
もう一度勉強し直してみます。

339 :デフォルトの名無しさん:2010/05/22(土) 22:10:49
>>307
職業プログラマじゃないからよくわからんのだけど、
「システム内通信」って何?
あと、ACEはよく知らない(使ったことない。超重量級のライブラリだってことは知ってるw)
から、参考意見だせないなぁすまそ

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

341 :デフォルトの名無しさん:2010/05/23(日) 08:17:57
ドメインソケットによる通信とか、LAN内のRPCのことだとはわかるけど、
「システム内通信」は初耳だなぁ

342 :デフォルトの名無しさん:2010/05/23(日) 08:51:59
いや普通にあるだろ。会社によって呼び方は違ったりすろけど。

343 :デフォルトの名無しさん:2010/05/23(日) 11:34:31
会社によって呼び方は違ったりするなら、それは普通にあるとは言わないんじゃないか?

344 :デフォルトの名無しさん:2010/05/23(日) 11:47:14
クローズド・システムにおける、
(しばしば独自のアプリケーション層プロトコルを使った)IPCってことか
昔なら電文とか言ってた奴だな

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

345 :デフォルトの名無しさん:2010/05/23(日) 12:36:43
システムの中で閉じた通信 ってことで字面でわかるんじゃね?

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

346 :デフォルトの名無しさん:2010/05/23(日) 12:46:07
まあ呼び名はどうあれ、主題(システム内通信? 独自プロトコル?)そのものは
誰も誤解していないと思われるから、細かい議論はいいんじゃねえか?

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

347 :デフォルトの名無しさん:2010/05/23(日) 12:58:47
>>346
データグラム型TCPという、聖なる矛盾に満ちた神プロトコルだからだろ。

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

348 :デフォルトの名無しさん:2010/05/23(日) 14:58:56
複数ルート使った冗長性も

349 :デフォルトの名無しさん:2010/05/23(日) 16:01:42
通信伝聞って書いて誰も違和感を感じなかったウチの社内。

350 :デフォルトの名無しさん:2010/05/23(日) 16:08:16
「電文」って90年代後半から使われなくなった気がする
やっぱWindows95以降かな

351 :デフォルトの名無しさん:2010/05/23(日) 16:57:59
>>350
マジか?
うちの仕事じゃ毎日のように使う用語なんだが遅れてるのかな・・・

352 :デフォルトの名無しさん:2010/05/23(日) 16:59:01
会社次第じゃない

353 :デフォルトの名無しさん:2010/05/23(日) 17:04:11
>>347
電文の切り出しなんかTCPでも電文長を頭に付ければ簡単に
出来るんだからSCTP使う理由になるわけない。

354 :デフォルトの名無しさん:2010/05/23(日) 17:26:52
>>353
>電文長を頭に付ければ
プッ

355 :デフォルトの名無しさん:2010/05/23(日) 17:29:15
>>353
電文長だけじゃダメだろ。
ヘッダ、電文長、本文、フッタ、サム
最低でもこんくらいいるだろ、齟齬無くやろうとしたら。

356 :デフォルトの名無しさん:2010/05/23(日) 18:03:10
TCPなのに?

357 :デフォルトの名無しさん:2010/05/23(日) 18:17:21
>>356
えっ?
データがおかしくなってもそのままおかしくなったまま被害が増大するのをほっとくの?

358 :デフォルトの名無しさん:2010/05/23(日) 18:46:55
勝手に要件追加するなよ

359 :デフォルトの名無しさん:2010/05/23(日) 18:47:36
>>357
ヘッダ、フッタにサム付きなんて、まるでベーシック手順全盛の時代を想い出すなぁ。
あぁ、そういやメッセージじゃなくて電文だったw

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

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

360 :デフォルトの名無しさん:2010/05/23(日) 19:11:18
>>357
TCPならデータはおかしくならないよ。

361 :デフォルトの名無しさん:2010/05/23(日) 19:40:25
IPは届いたデータがおかしくならない事を保証している。

362 :デフォルトの名無しさん:2010/05/23(日) 19:43:31
>>356
ストリームだからだろ。

363 :デフォルトの名無しさん:2010/05/23(日) 19:45:07
>>359
だから通信順序の保証されたUDPみたいな使い方が出来て便利だよ

364 :デフォルトの名無しさん:2010/05/23(日) 19:46:09
>>362
どこまで話を戻したいんだよw
ストリームだと「なぜ」チェックサムが要るんだか言ってみろ

365 :デフォルトの名無しさん:2010/05/23(日) 20:00:29
最低限ヘッダかフッタは必要だな

366 :デフォルトの名無しさん:2010/05/23(日) 20:01:35
そういう意味じゃ改行ってフッタだな

367 :デフォルトの名無しさん:2010/05/23(日) 20:06:20
まあ、もちついて、ここらでも読んでそれからだ

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

368 :デフォルトの名無しさん:2010/05/23(日) 20:07:29
>>367
マルチストリーミングのところがよくわからん
解説してくんろ

369 :339:2010/05/23(日) 20:38:29
>>353
簡単ではあるが、それがカーネル内でやってくれるというのは効率上大きな意味があると
思います。 切り分けが、カーネルと往復せずに処理されるという所に意味があると。


370 :デフォルトの名無しさん:2010/05/23(日) 20:48:14
ちょっと質問
TCP通信で、途中のパケットが失われることってある?

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

371 :デフォルトの名無しさん:2010/05/23(日) 20:52:27
>>370
入り口から入ったものと出口から出てきたものが同じであることを保障してくれるのがTCP

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



372 :デフォルトの名無しさん:2010/05/23(日) 21:06:14
>>368
一つの接続の中に複数のストリームを流せると読んだ

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

374 :デフォルトの名無しさん:2010/05/23(日) 21:18:45
こにちは。C#2010入れたみたけど、C#でのTCPクライアントプログラムングでお勧めはあるますか?
ttp://www.yoihon.com/sc/product-84512.html
この本はいかがでしょうか?感想お知らせください。ませ。

375 :デフォルトの名無しさん:2010/05/23(日) 21:26:57
SCTPの利点は以下の通り。

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

376 :デフォルトの名無しさん:2010/05/23(日) 22:15:21
>>371
つまり、Bが失われたときはCは来ないってことでおk?

377 :デフォルトの名無しさん:2010/05/24(月) 00:00:15
>>376
Bの再送が失敗に終わればCは来ない


378 :デフォルトの名無しさん:2010/05/24(月) 08:54:49
>>377
ありがとう!

379 :デフォルトの名無しさん:2010/05/24(月) 22:40:17
レイヤ7でいれるチェックサムはTCPでのチェックサムっていう意味じゃなくて、
(フレーム単位でのチェックサムではなく、)
セキュリティ的に改竄されてるかどうかとかそういうチェックサム。
(レイヤ7上でのプロトコルで改竄検出をするための)

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

381 :デフォルトの名無しさん:2010/05/27(木) 21:42:01
wininetのInternetOpenとInternetOpenUrlとInternetReadFileを使って、
yahooのページも何ページもダウンロードするプログラムを作ったのですが、
何ページ目かのInternetOpenUrlがerror code12152(ERROR_HTTP_INVALID_SERVER_RESPONSE)を返します。
yahooが連続アクセスを拒否したという事なのでしょうか?

382 :デフォルトの名無しさん:2010/05/27(木) 23:09:23
>>381
そういうことです

383 :デフォルトの名無しさん:2010/05/28(金) 05:08:01
【社会】 図書館HPにアクセス3万3千回で、会社社長逮捕。1秒に1回アクセス繰り返すプログラム作る…愛知
http://tsushima.2ch.net/test/read.cgi/newsplus/1274928007/


384 :デフォルトの名無しさん:2010/05/28(金) 07:09:15
21回も鯖落としても給料に反映無しってのがお役人さね。
Windows Server 2003 Microsoft-IIS/6.0 26-May-2010 202.238.45.27 Okazaki City Library
IIS6で5クライアント超えただけとかいうオチなら笑いもの

385 :デフォルトの名無しさん:2010/05/28(金) 10:30:29
>>382
やはりそうですか・・・。

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

386 :デフォルトの名無しさん:2010/05/28(金) 11:02:37
図書館の検索なんかは GET リクエストじゃなくて POST リクエストだから、
普通のロボットは retrieve しない。

387 :デフォルトの名無しさん:2010/05/28(金) 13:19:49
鯖を落としたとは書いてないんだけどな。

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

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

388 :デフォルトの名無しさん:2010/05/28(金) 17:17:25
1tpsで重くなるって弱っちすぎる。
地方自治体の図書館なんてどこもヘボが作ってるんだろうな。

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

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

389 :デフォルトの名無しさん:2010/05/28(金) 22:12:26
たしてちょうど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;
}

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

390 :デフォルトの名無しさん:2010/05/28(金) 22:13:54
言語はC++
環境はVisual です。

391 :デフォルトの名無しさん:2010/05/28(金) 22:16:46
数十文字のスレタイも読めなんだから入門書なんて読みもしないんだろうな

392 :デフォルトの名無しさん:2010/05/28(金) 22:29:21
>>391
すいません。間違えました。

393 :デフォルトの名無しさん:2010/05/29(土) 14:10:09
>>388
うちもだよ
蔵書検索に30秒くらいかかる

394 :デフォルトの名無しさん:2010/06/04(金) 23:18:12
>>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のシステム次第だと思いますが、
一般的にアクセスを拒否する仕組みはどのような物があるのでしょうか?
なんとかしてプログラムでダウンロードしたいです。

395 :デフォルトの名無しさん:2010/06/04(金) 23:36:34
>>394
エラーの詳細は?

396 :デフォルトの名無しさん:2010/06/04(金) 23:56:35
>>395
>>381の3行目に書いた事しか分からないです。

397 :デフォルトの名無しさん:2010/06/05(土) 04:16:12
専用ブラウザの書き込み通信をモニターして、書き込みがあった場合
次の書き込み可能な時間が来るまでのカウントダウン表示をする
アプリを作りたいのですがどのようにすればいいのでしょうか?

398 :デフォルトの名無しさん:2010/06/05(土) 15:16:17
>>396
バケットキャプチャは?

399 :デフォルトの名無しさん:2010/06/05(土) 19:26:32
>>398
Wiresharkで見てみたんですけど、データの見方がわからないです。
通信は難しいなぁ・・・。

400 :デフォルトの名無しさん:2010/06/05(土) 22:15:48
>>399
なんかコードがバグってる気がするな
10秒間隔でWebブラウザで開く分には問題よね?

401 :デフォルトの名無しさん:2010/06/06(日) 02:19:42
総務省が日本のISPを巻き込んで検閲するって本当なの?
それもパケットキャプチャレベルじゃなくてISPでキャプチャするユーザパケットレベルで検閲する(広告利用とか言ってるけど実際は検閲のこと)ってので、
現在中国やグーグルがやってる検閲以上のを検証してるようだけど。

402 :デフォルトの名無しさん:2010/06/06(日) 03:55:26
ゆくゆくは総務省が財務省や外務省の通信内容を全部検閲しようって腹積もりだよ。

403 :デフォルトの名無しさん:2010/06/06(日) 04:10:05
既に中国やアメリカからハッキングされて筒抜けなのに、さらに国策レベルで自分の首をしめるようなものだよな。

404 :デフォルトの名無しさん:2010/06/06(日) 05:24:44
なんの話?児童ポルノ対策の話?

405 :デフォルトの名無しさん:2010/06/06(日) 06:55:25
>404
http://headlines.yahoo.co.jp/hl?a=20100605-00000003-jct-sci

406 :デフォルトの名無しさん:2010/06/06(日) 09:01:36
>>400
ブラウザで更新ボタンを何回も押すのは問題なくできます。
再度、コードをチェックしてみます。

407 :デフォルトの名無しさん:2010/06/06(日) 09:31:24
>>405
こういうのって、昔から過剰に反応する人がいるんだよな
昔はパソコンに疎いおっさんが、中の動作を知ったときにわめくことが多かったけど

408 :デフォルトの名無しさん:2010/06/06(日) 09:39:38
>>403 みたいな病人もいるしな

409 :デフォルトの名無しさん:2010/06/06(日) 09:49:11
一般人には専門的なことはわからんよ。
重要なのは恐怖だ。

410 :デフォルトの名無しさん:2010/06/06(日) 10:34:11
いや、違反者への罰則は外患誘致みたいに死刑のみにしないと、
クズがデータを転売するに決まっている。

411 :デフォルトの名無しさん:2010/06/06(日) 10:52:54
WindowsでTCP/IPサービスが利用できるかチェックするいい方法はありますでしょうか?
たとえば、LANならロカールエリア接続が有効になっていて、TCP/IPプロトコルが有効になっていて、
とかそういうのをひっくるめて。しかもすごい頻繁にチェックするのですが。

412 :デフォルトの名無しさん:2010/06/06(日) 11:01:33
>>411です。
ああ、頻繁じゃなくてもいいです。タイマーか何かで定期的にチェックして
その結果でフラグセットしますので。

413 :デフォルトの名無しさん:2010/06/06(日) 13:14:53
>>405
ネット情報すべて解析する技術 利用者から「使用やめろ」の大合唱
6月5日18時12分配信 J-CASTニュース

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

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

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

415 :デフォルトの名無しさん:2010/06/06(日) 15:28:39
>>411
netsh

416 :デフォルトの名無しさん:2010/06/07(月) 01:15:42
>>411
acceptして放置

417 :デフォルトの名無しさん:2010/06/07(月) 01:19:22
ネットワークを扱った書籍で、子供だましな誰得?なサンプルアプリとか
やってはいけない馬鹿の見本なサンプルコードとかじゃなく
まじめにきちんと設計されたアプリを書き上げた書籍ってありますか?

418 :デフォルトの名無しさん:2010/06/07(月) 01:44:33
>>417
UNIXネットワークプログラミング<Vol.1>
がもっとも要求に近い。

419 :デフォルトの名無しさん:2010/06/07(月) 05:13:07
>>417
なんでオープンソースのコードを読まないの?

420 :デフォルトの名無しさん:2010/06/07(月) 19:55:48
TCPDUMPについて質問させてください

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

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

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

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

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

422 :デフォルトの名無しさん:2010/06/07(月) 20:30:14
近所にミニブタ飼ってて奥さんが颯爽と散歩兼ねてジョギングしてる。
真珠かイミテーションか知らんが結構似合うモンだぜ?豚に真珠。

423 :デフォルトの名無しさん:2010/06/07(月) 20:38:55
で、>>417には似合うのか?

424 :デフォルトの名無しさん:2010/06/07(月) 20:54:13
>>420
IPってゆうな。クズ。

425 :デフォルトの名無しさん:2010/06/07(月) 23:06:15
>>420

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

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


426 :デフォルトの名無しさん:2010/06/07(月) 23:43:59
そういえば、「バイト数の節約になるんだ」とかいって
EUCやUTF8でも半角かなを使っている人がいたな。
今でも元気にしてるかな・・・

427 :デフォルトの名無しさん:2010/06/07(月) 23:49:13
そういう奴ほど元気で長生きなものだ

428 :デフォルトの名無しさん:2010/06/07(月) 23:50:15
半角カナ駄目とかいう暴論者は10年ほど前に絶滅したと思ったらまだいたんだな…

429 :デフォルトの名無しさん:2010/06/07(月) 23:52:00
半角かなの特性を正しく理解せずに使っているのが癇に障るんだろう

430 :デフォルトの名無しさん:2010/06/07(月) 23:55:30
今時7ビットしか受け付けないメールサーバなんてあるんですか?

431 :デフォルトの名無しさん:2010/06/07(月) 23:57:46
悪魔の証明は不可能だよ

432 :デフォルトの名無しさん:2010/06/08(火) 00:02:52
そういえば外人って°とか℃とかuとかどうやって入力してるんだろう?

433 :デフォルトの名無しさん:2010/06/08(火) 00:32:10
degreeとかdegree celsiusとかsquare meterとか書いちゃうよw

434 :デフォルトの名無しさん:2010/06/08(火) 01:32:36
>>421のせいで基本的なネットのリテラシも無い、やってはいけない馬鹿の見本のような
カキコを平気でする奴が出てきた。もう何を言っても馬の耳に念仏だお。

435 :デフォルトの名無しさん:2010/06/08(火) 08:19:40
>>420
tcpdump > tcpdump.txt

436 :デフォルトの名無しさん:2010/06/08(火) 09:17:04
結局半角カナを使う馬鹿って生き残っちゃったよな

437 :デフォルトの名無しさん:2010/06/08(火) 09:58:26
>>436
(゚∀゚)これも半角だしNE!

438 :デフォルトの名無しさん:2010/06/08(火) 09:58:26
文字コードとして割り当てがあるのに使ってはいけないとか言う子の意図がわからんな


439 :デフォルトの名無しさん:2010/06/08(火) 10:03:53
>>438
8bit->7bit変換のときに単純に8bit目を落とす馬鹿鯖があるからだろ

440 :デフォルトの名無しさん:2010/06/08(火) 10:27:00
ISO-2022-JPでは使わないことになってるエスケープなのに、使っていいとか思ってる子の意図がわからんな

441 :デフォルトの名無しさん:2010/06/08(火) 11:44:09
>>440
ISO-2022-JP以外なら使ってもいいってことだから問題ないよ。
ISO-2022-JPに変換しなければおk

442 :デフォルトの名無しさん:2010/06/08(火) 11:52:15
バカっぽく見えるから使わない方がいいよ。逆にバカっぽさを強調したい場合には使うのもあり。

443 :デフォルトの名無しさん:2010/06/08(火) 12:31:39
こいつらの作るアプリはさぞ使いにくいだろうなw

444 :デフォルトの名無しさん:2010/06/08(火) 13:52:53
黙れ
ネトウヨ

445 :デフォルトの名無しさん:2010/06/08(火) 14:22:12
>>444
極めて正しい用法。

446 :デフォルトの名無しさん:2010/06/08(火) 14:34:03
>>442
イッテヨチ!

447 :デフォルトの名無しさん:2010/06/08(火) 18:19:01
>>442
半角かなを使わないに越したことは無いが
半角かなを受け入れられないソフトは糞だ。

448 :デフォルトの名無しさん:2010/06/08(火) 18:37:39
半角カナ駄目とか30年前からタイムスリップしてきたのか?w

449 :デフォルトの名無しさん:2010/06/08(火) 18:57:57
半角カナ使う奴の方が30年前からタイムスリップして来てるのだが

450 :デフォルトの名無しさん:2010/06/08(火) 19:53:41
両方使えるようにすればいいだけじゃん。
エンドユーザーなんて何するかわからん。

451 :デフォルトの名無しさん:2010/06/08(火) 21:46:57
梢レ?

452 :デフォルトの名無しさん:2010/06/08(火) 21:58:09
>>440
つまり@A……も禁止か?"−"もだめそうだが?


453 :デフォルトの名無しさん:2010/06/08(火) 22:04:14
潔く捨てるのがルータの教え。
利用者に使えないんだと理解させるためにicmpで通知してあげればいい。

454 :デフォルトの名無しさん:2010/06/08(火) 22:06:26
icmpてピングでしょ?どうやって通知するの?

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

456 :デフォルトの名無しさん:2010/06/08(火) 22:14:26
昭和時代はカタカナでメールを打つのが常識だったんですか?

457 :デフォルトの名無しさん:2010/06/08(火) 22:35:17
ポケベルで数字打つってのが常識でした。

458 :デフォルトの名無しさん:2010/06/08(火) 22:39:27
53 93 65 05

459 :デフォルトの名無しさん:2010/06/08(火) 23:38:50
実に滑稽w
そのうち時代後れな事を言ってる奴が”文字化けするから「表」「予」「申」「能」「十」「ソ」なんかの文字も使うな!”とか言いだしそうだぜw

460 :デフォルトの名無しさん:2010/06/08(火) 23:43:18
\表

461 :デフォルトの名無しさん:2010/06/08(火) 23:56:26
森鴎外叱る

462 :デフォルトの名無しさん:2010/06/09(水) 00:00:06
>>459
俺鬱
JIS-X2010

463 :デフォルトの名無しさん:2010/06/09(水) 00:04:13
>>459 半角カナを使うような無神経な奴ほど、トラブルに対してそういう対応をするけどな。俺の経験上。

464 :デフォルトの名無しさん:2010/06/09(水) 00:27:49
エスケープするなら表\だろ。

465 :デフォルトの名無しさん:2010/06/09(水) 01:01:47
>>463
おまえの負け

466 :デフォルトの名無しさん:2010/06/09(水) 15:59:50
検索で半角カナと全角カナを厳密に区別するソフトとかあるからなー
必要に迫られない限り、使わないにこしたことないでしょ。機種依存文字なんだし

467 :デフォルトの名無しさん:2010/06/09(水) 17:44:39
バカっぽい雰囲気を出したいときは必須。

468 :デフォルトの名無しさん:2010/06/09(水) 17:52:08
一般の人の反応: 昔は使えなかったとかごちゃごちゃ言ってるけど、
今は使えてるんだからい〜じゃん、あほくさ


469 :デフォルトの名無しさん:2010/06/09(水) 19:17:06
>>420
Wireshark(Ethereal)に付いているコマンドラインツールのどれかに、
そういう機能があったと思う。

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


470 :デフォルトの名無しさん:2010/06/10(木) 10:46:48
プゲラ

471 :デフォルトの名無しさん:2010/06/11(金) 01:21:14
初歩的な質問
UDPのパケットがフラグメントとかされて途中で分断されてても
アプリケーション層でrecvfrom成功した時は送信されたパケットと同じサイズの
データの取得は保証されてる?

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

472 :デフォルトの名無しさん:2010/06/11(金) 01:27:40
眠いのかい?

473 :デフォルトの名無しさん:2010/06/11(金) 01:47:34
>>471
到達しない。

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

474 :デフォルトの名無しさん:2010/06/11(金) 09:01:50
>>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毎の独立バッファ
で受信しないといけなくて凄く実装が面倒なんだけど・・・


475 :デフォルトの名無しさん:2010/06/11(金) 09:14:32
>>474
ない。
もしどっかでちょん切れたら最後の50はうしなわえう

476 :デフォルトの名無しさん:2010/06/11(金) 10:45:36
>もしどっかでちょん切れたら最後の50はうしなわえう
ちょっと待て。
「最後の50」だけ失われるケースはありえないだろ。

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

477 :デフォルトの名無しさん:2010/06/11(金) 11:21:44
データ部が548バイトまでなら絶対分割されないから、分割が心配ならそのサイズまででやればいい。
548バイト超えると分割されたり、再送がどうだの発生したりで性能劣化していくし

あってるよね?

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

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

479 :デフォルトの名無しさん:2010/06/11(金) 20:26:35
>>476
分割するハメになったら破棄されるんだから、結合はないよね?
もしかしてあるの?

480 :デフォルトの名無しさん:2010/06/12(土) 10:35:20
パケットロスや順番入れ替えが無かったと仮定して。
sendtoで"A""B"..."Z"と一文字ずつ26回送った場合
受信側はrecvfrom一回で"ABC..."とかくっついて受信されずに
recvfromを26回、一回につき一文字ずつ受信できるのは保証されてるのかな?

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

481 :デフォルトの名無しさん:2010/06/12(土) 11:45:55
そもそも、そんなことを気にしなきゃならないような通信を
UDPで実装しようって設計が間違ってる気がする

482 :デフォルトの名無しさん:2010/06/12(土) 11:59:34
>>480
それが書いていない教科書はクソだし、検索すればいくらでも出てくる。

483 :デフォルトの名無しさん:2010/06/12(土) 12:04:43
>>480
作るときはパケットの区切りは、どこか分からないものとして作るんだよ
ここが区切りですなんて情報はくっついて来ないから


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


484 :デフォルトの名無しさん:2010/06/12(土) 12:30:19
>>483
> 作るときはパケットの区切りは、どこか分からないものとして作るんだよ
それはTCPだけ。 UDPはおk。

485 :デフォルトの名無しさん:2010/06/12(土) 12:40:33
>>482
とりあえず1冊入門書読んだんだけど見つからなかったんだ・・・
UDPのRFC読んだけどそう動作するよう実装するべし、みたいなのが見つからなくって
ネットで探した限りSUNのページにそれらしい記述があったけどSUNの実装が
そうなってるだけでBSDソケットと名乗るなら必ずそう動作する、って保証はあるのかなぁ、と

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

486 :デフォルトの名無しさん:2010/06/12(土) 13:00:20
>>485

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

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

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


487 :デフォルトの名無しさん:2010/06/12(土) 13:04:31
>>485
UNIXネットワークプログラミング<Vol.1>
を買ってこい。今すぐ!ダッシュでだ!

488 :デフォルトの名無しさん:2010/06/12(土) 13:08:52
>>486
UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、
で使う側の実装はまったく違うものになると思うが・・・

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


489 :デフォルトの名無しさん:2010/06/12(土) 13:26:39
>>488
>UDPではsendto/recvfromは1:1対応してると期待していいのかどうか、

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

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



490 :デフォルトの名無しさん:2010/06/12(土) 13:34:59
>それ以前に到達することすら保障されてないわけだが、そこはいいの?
UDP使うしか無い以上その保証はアプリ側で対処するしか無いです。車輪の最発明は嫌だけど・・・

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

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



491 :デフォルトの名無しさん:2010/06/12(土) 13:42:53
>>488
期待しなきゃだめだろ
その代わり順番も入れ替わるし無くなることもあるというだけの話

492 :デフォルトの名無しさん:2010/06/12(土) 14:21:44
>>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対応を期待できるなら大丈夫だね。

493 :デフォルトの名無しさん:2010/06/12(土) 15:14:45
>>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ソケットの位置づけを誤解している。

494 :デフォルトの名無しさん:2010/06/12(土) 17:24:35
>>478
> で、一般的なUDP実装では、このフラグは「常に」不可に設定される。
いつからそうなった?

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

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


495 :デフォルトの名無しさん:2010/06/12(土) 18:20:02
>>493
RFC1180にあったのか。これってTCPだけじゃなくUDPについても書いてあったんだね。
UDPだからRFC768を見てた。さんくす

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

496 :デフォルトの名無しさん:2010/06/12(土) 20:23:52
>>495
BSDソケットはAPI, プロトコルではない。

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

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


498 :デフォルトの名無しさん:2010/06/13(日) 11:54:44
> 「Berkeley 互換を名乗るなら動作を含めて互換にしてほしい」ってのはわがまま?
やっぱりAPIだと言う事を理解していない
APIだから、socket(PF_INET,...)がEPROTONOSUPPORTを返したってBSDソケットの正しい実装。

499 :デフォルトの名無しさん:2010/06/13(日) 12:10:10
APIって、セマンティック含めてAPIだろ。
名前が同じならいいってもんじゃない。

500 :デフォルトの名無しさん:2010/06/13(日) 12:35:56
BSDソケットは、特定のプロトコルの実装を要求していない。

501 :デフォルトの名無しさん:2010/06/13(日) 14:02:52
>>498
API ってのは, 仕様があってはじめて API って名乗れるもんではないのか?
Berkeley の仕様なんてどこにもないんだが…

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

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


502 :デフォルトの名無しさん:2010/06/13(日) 14:17:33
下らない言いがかりをつけるのはキミの自由だけど、世の中の大部分の人はAPIだと考えている。
http://en.wikipedia.org/wiki/Berkeley_sockets

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

503 :デフォルトの名無しさん:2010/06/13(日) 15:07:30
>>501
manすら見たことない事を全力で告白しなくても良いぞ。

504 :デフォルトの名無しさん:2010/06/17(木) 19:16:24
Windows でネットワークプログラミングを始めました。
Linux ではちょっとやっていたことがあります。

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

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


505 :デフォルトの名無しさん:2010/06/17(木) 19:36:19
>WSAGetLastError はスレッドセーフなのでしょうか。

いいえ

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

WSAGetLastError を使わない

506 :デフォルトの名無しさん:2010/06/17(木) 19:57:55
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.

507 :504:2010/06/17(木) 20:14:20
英語はあんまり得意じゃないんで読み間違ってたらすみませんが、
>>506
>The return value indicates the error code for this thread's last Windows Sockets operation that failed.

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


508 :デフォルトの名無しさん:2010/06/17(木) 20:19:09
ただのアホの戯言ですよ

509 :デフォルトの名無しさん:2010/06/17(木) 23:48:19
>>502 すまんな、急な出張が入ってた
それは *nix とか, Windos とかの資源が潤沢なところの世界の話だ


510 :デフォルトの名無しさん:2010/06/18(金) 01:02:25
>>504
1つのスレッドで 1つのsocketを扱っているならWSAGetLastErrorを
複数スレッドで同時に呼んでも全く問題なし。

511 :デフォルトの名無しさん:2010/06/18(金) 01:13:42
1つのスレッドでWSAGetLastErrorを*同時に*呼ぶ事はできないから
WSAGetLastErrorの使用に関して条件を付ける必要は無い。

512 :デフォルトの名無しさん:2010/06/18(金) 05:30:22
>>510
アホはいい加減黙れ

513 :デフォルトの名無しさん:2010/06/18(金) 14:55:10
メールのプロトコル(SMTP/POP3)に関して勉強したいのですが、お勧めの書籍などありますでしょうか?

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

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

514 :デフォルトの名無しさん:2010/06/18(金) 15:19:01
SMTP と POP3 だけなら RFC(の日本語訳)サイト で十分じゃね?

515 :デフォルトの名無しさん:2010/06/18(金) 15:38:12
ちょww誰がうまい事をいえと言ったw
http://stream.everywebhost.com/hitec/sport/j7.html

516 :デフォルトの名無しさん:2010/06/18(金) 18:50:25
これ見てよ↓
http://livedoor.blogimg.jp/tekepo/imgs/3/4/3414dfca.jpg
ばらまこうぜ!


517 :デフォルトの名無しさん:2010/06/18(金) 19:50:36
>>516
自分で拡散してお前がアク禁食らえ。カス。

518 :513:2010/06/19(土) 00:23:33
>>514
いや、まぁ、確かに最後に見るのはソコなんでしょうが・・・。
出来ればもう少しナンパな本は無いでしょうか?(苦笑

519 :デフォルトの名無しさん:2010/06/19(土) 00:25:40
最後じゃねえよ最初に見ろドアホ

520 :デフォルトの名無しさん:2010/06/19(土) 01:21:29
>>518
> ※ライブラリやアプリケーションの使い方の質問ではない
ということから、少なくともソケット操作はできる前提
→ なら SMTP POP3 のプロトコルの話
→ 結局 RFC が全て
こういうことだ。 で、その部分だけを書籍化するのは… …(とても少ないという意で)厳しいか?

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

521 :デフォルトの名無しさん:2010/06/19(土) 01:25:29
優秀wな人材wが束になって時間wと金wをかけて作ったメーラーが
十年単位でバグだらけだった事実

522 :デフォルトの名無しさん:2010/06/19(土) 03:05:35
OE

523 :デフォルトの名無しさん:2010/06/19(土) 12:08:04
メーラーでトラブルのは文字のエンコード/デコード周辺じゃねーの?
SMTP で送る/POP3 で受ける 部分はそんなに複雑じゃないと思われ

524 :513:2010/06/20(日) 11:18:12
なるほど、申し訳ありませんでした。
メールに関しては、RFC<MIMEや文字エンコード、なのですね。
では改めて、そのあたりも含めて、(大爆発しない程度に(汗))解説している書籍などはありますでしょうか?
とりあえず>>513は二冊とも通販で注文を出しました。

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

525 :デフォルトの名無しさん:2010/06/20(日) 11:34:42
人の話をきけよ!

526 :デフォルトの名無しさん:2010/06/20(日) 23:47:31
>>524
RFCに全部書いてあるし変な本より読みやすいから
直接読むのをおすすめする

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

527 :デフォルトの名無しさん:2010/06/21(月) 01:33:06
なんつーか
"RFC読める俺かっこいい"とか
"俺はRFCを読んで苦労してるんだおまえも苦労しろ"
みたいな意味を含んだレスって読んでて痛いよなぁ
こう言う事言う人って生産性のない学生に多いのよね…

528 :デフォルトの名無しさん:2010/06/21(月) 02:26:21
そんな人はいないように見えるんだが、君はそんな風に感じたのかい?

529 :デフォルトの名無しさん:2010/06/21(月) 02:28:45
世の中には辞書が読みやすいという変態がいる
だからrfcが読みやすいとかいう変態がいても不思議ではない

530 :デフォルトの名無しさん:2010/06/21(月) 02:31:06
rfcは辞書じゃないし

531 :デフォルトの名無しさん:2010/06/21(月) 03:24:29
>>527
RFCが何だかわかって言っているの?

532 :デフォルトの名無しさん:2010/06/21(月) 10:15:36
生産性のある社会人はRFCを読まずに俺様解釈とコピペで仕事するので、
クズ実装を非常に高い生産性で排出するわけですね、わかります。

533 :デフォルトの名無しさん:2010/06/21(月) 10:24:52
>>527
三流底辺技術者の言いそうな台詞だなw

534 :デフォルトの名無しさん:2010/06/21(月) 11:53:02
>>532
マイクロソフトの悪口はそこまでだ

535 :デフォルトの名無しさん:2010/06/22(火) 22:04:42
初歩的な質問ですみません
connect/acceptでクライアントとサーバが接続状態であるなか
どちらかがclosesocketしたら、recvが失敗して初めて切断されたと分かるんですか?

536 :デフォルトの名無しさん:2010/06/22(火) 23:29:45
>>535
同期ソケットなら普通はrecvの前にselectして検知するな

537 :デフォルトの名無しさん:2010/06/23(水) 00:55:27
>>536
えらいなー。俺面倒だから切断処理は全部recvでやっちゃうわ。
つーか通常切断されるとselectは正常に抜けてきちゃうから
readとかで0バイト受信かどうかを見るのが一番ラクダと思う

538 :デフォルトの名無しさん:2010/06/25(金) 02:05:54
WindowsXPとUPnP対応のルータで、NAT超えの簡単な通信プログラムの
サンプルはないでしょうか?

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


539 :デフォルトの名無しさん:2010/06/25(金) 07:22:13
>>538
vmware

540 :デフォルトの名無しさん:2010/06/25(金) 13:33:19
>>538
http://miniupnp.free.fr/

541 :デフォルトの名無しさん:2010/06/25(金) 21:01:18
>>538
VC++でよければ晒すが

542 :デフォルトの名無しさん:2010/06/26(土) 12:51:18
socketを使ったプログラミングって、受信と送信の両方をプログラミングしないとダメなんですか?

543 :デフォルトの名無しさん:2010/06/26(土) 12:55:14
一方通行のプロトコルならば片方でOK。

544 :542:2010/06/26(土) 13:16:51
>>543
thx

545 :デフォルトの名無しさん:2010/06/26(土) 14:43:24
>>543
ミサカネットワークに接続するんですね

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


547 :デフォルトの名無しさん:2010/06/26(土) 16:59:46
うんそうだよ
自分でプロトコルを実装しないといけない。

548 :デフォルトの名無しさん:2010/06/26(土) 18:22:57
>>546
たいした量じゃないなら毎回「状態」を送るのも手だな。
エッジトリガじゃなくてレベルトリガで動作するようにする、と。

549 :デフォルトの名無しさん:2010/06/26(土) 21:29:43
>>546
そういうのはゲームが開始されるまではTCPで面倒見るのが楽。
1:1なら開始するまでリトライすればいいから楽だが、
1:他になったときにUDPだけだとスゲー面倒だよ。
参加者のうち一人がサーバーになって、皆でTCPでサーバーに接続して
ゲーム開始情報とかはサーバーから一貫した情報送るとかいう仕様にすれ。

550 :デフォルトの名無しさん:2010/06/26(土) 22:25:49
よくよく考えたら全部TCPでよかったわ
ありがとう

551 :デフォルトの名無しさん:2010/06/28(月) 00:12:28
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");

552 :デフォルトの名無しさん:2010/06/28(月) 02:15:56
そうですか。

553 :デフォルトの名無しさん:2010/06/28(月) 08:37:18
>>551
winsock fgets でぐぐる

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

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

555 :デフォルトの名無しさん:2010/06/28(月) 17:54:57
いくらなんでも基本中の基本すぎて、釣りにしか見えん。
でも釣りじゃなかったら可哀そうだから答えるけど

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

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

556 :デフォルトの名無しさん:2010/06/28(月) 18:09:13
>>555
'\n' を受け取るまで受信側が recvを繰り返す (fgets を意識した感じ
recv の受信バイト数が 0 になるまで繰り返す (=切断されるまで読みっぱー)
もありそうな話やね

557 :デフォルトの名無しさん:2010/06/28(月) 19:21:13
釣りじゃないッすorz
ほんと可哀そうなやつで申し訳ない
んで丁寧に教えてくれてほんとにありがとう

558 :デフォルトの名無しさん:2010/06/28(月) 19:39:33
俺は>>551の1行目で釣りとわかったぜ

559 :デフォルトの名無しさん:2010/06/28(月) 20:21:51
おまいら叩き過ぎだろ。できの悪い本なら
Send1回につきRecv1回で取れる保障がないこと自体書いてないぞ
ネコわかとかな。

560 :デフォルトの名無しさん:2010/06/28(月) 21:47:35
できの悪い本の話なんてどうでもいいんだが?

561 :デフォルトの名無しさん:2010/06/29(火) 00:18:02
できの悪い本手に取ったならそういう質問がでてもおかしくないって話してるんだが。
まー最初からWinsock Programmer's FAQあたり読んだほうがマシだな。

562 :デフォルトの名無しさん:2010/06/29(火) 00:19:25
そんな話してないよ?

563 :デフォルトの名無しさん:2010/06/29(火) 00:53:58
2chもレベル落ちたな

564 :デフォルトの名無しさん:2010/06/29(火) 00:55:57
>>553でrecvをreadって書いちゃったはずかひい

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

565 :デフォルトの名無しさん:2010/06/29(火) 02:16:14
CMSを自作したいんですが
javaサーブレットとPHP どっちがいいですか
データベースはたぶん使いませんん
Webアプリケーションとの連携がしたいです

566 :デフォルトの名無しさん:2010/06/29(火) 22:40:58
なんで設計をすっ飛ばして製造に入ろうとするんだろうな

567 :デフォルトの名無しさん:2010/06/29(火) 22:45:23
早漏でござる早漏

568 :デフォルトの名無しさん:2010/06/29(火) 23:45:31
P2PのDHTを作ってるのだけれども
UDPで実装なんだけども
UDPはパケットサイズ512以下じゃないと届かないことがあるとか言いますが
未だにそんなごみルーターがごろごろしてるの?
今時サイズなんて気にしなくてもたいして支障はないのかな?

569 :デフォルトの名無しさん:2010/06/29(火) 23:55:52
サイズが小さくても届かないときは届かない

570 :デフォルトの名無しさん:2010/06/30(水) 00:08:23
>>569
そんなことは分かってる
DHTは最初からそれを考慮して設計されてるから問題ない
聞いてるのは最近のルーター事情において
512と1024では届く確率に差が出るのかということ

571 :デフォルトの名無しさん:2010/06/30(水) 00:14:17
pgr

572 :デフォルトの名無しさん:2010/06/30(水) 00:16:02
>>570
1500超えなきゃまず大丈夫じゃね?
1500超えてもIPパケット分割されっし結構いけるんじゃね?

573 :デフォルトの名無しさん:2010/06/30(水) 00:56:12
log2n2の確立で差異が出るが、ルーター事情によるものではない。
送信間隔はどのくらいのしてる?
10ms以下のインターバルで送信しまくったりしてないよね?

574 :デフォルトの名無しさん:2010/06/30(水) 00:58:24
MTUの設定値が低い場合は差異がでるかもしれんね

575 :デフォルトの名無しさん:2010/06/30(水) 12:04:20
>>572-574
なるほど、その言葉を信じてとりあえずやってみる

576 :デフォルトの名無しさん:2010/06/30(水) 13:25:20
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 :デフォルトの名無しさん:2010/06/30(水) 13:36:46
ルーター事情ならだめなものはだめ、いけるものはいけるで
確立云々ではないだろう
確立的に届いたりとどかなかったりするのは、回線事情のほうでしょ



578 :デフォルトの名無しさん:2010/06/30(水) 14:38:47
>>577
P2Pって書いてる通り特定の経路を前提にしてないから
古いルーターにぶち当たる確率です

579 :デフォルトの名無しさん:2010/06/30(水) 15:39:10
>>578

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

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

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


580 :デフォルトの名無しさん:2010/06/30(水) 22:20:07
>>579
そういうのに当たる確率の話でしょ

581 :デフォルトの名無しさん:2010/07/01(木) 13:59:05
>>579
古いというかバグというか、それ以前のルータが氾濫してるんだ。

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

582 :デフォルトの名無しさん:2010/07/01(木) 14:36:40
世の中のルータがアホである確率をAとちたとき
n回ルータ通るときにアホに引っかからない確率
(1-(1/A))^n

583 :デフォルトの名無しさん:2010/07/01(木) 15:07:22
1/Aって?

584 :デフォルトの名無しさん:2010/07/01(木) 15:16:34
>>583
間違いだ

585 :デフォルトの名無しさん:2010/07/01(木) 18:37:59
(1-A)^nだね

586 :デフォルトの名無しさん:2010/07/01(木) 19:09:55
で、Aは?

587 :デフォルトの名無しさん:2010/07/01(木) 19:41:19
A<<1
よって
1

588 :デフォルトの名無しさん:2010/07/08(木) 02:23:31
でも、確立は確定じゃないからね

589 :デフォルトの名無しさん:2010/07/08(木) 03:31:10
確率が確定する確率は確立してない

590 :デフォルトの名無しさん:2010/07/08(木) 14:49:41
確率を確立する確率を書く律

591 :デフォルトの名無しさん:2010/07/08(木) 22:19:43
リッチャアアアアアアアアアン!

592 :デフォルトの名無しさん:2010/07/09(金) 02:52:41
PINGのような即答パケットの場合はタイムアウトはどれくらい取ればいいんだろう?
あんまり短いとタイムアウトが頻発するだろうし、
あんまり長いと応答待って次の行動を起こすような処理ではかなりの遅延になる

593 :デフォルトの名無しさん:2010/07/09(金) 08:49:48
>>592
悪いが1秒だ

594 :デフォルトの名無しさん:2010/07/09(金) 12:46:18
>>592
何が目的のPINGなの?
593じゃないがゲームとか速度が要求される通信するなら
1秒超えるやつは無視でいいかもね

595 :デフォルトの名無しさん:2010/07/12(月) 22:10:20
socket layer ってosi参照モデルのネットワーク層でいいんですか?

596 :デフォルトの名無しさん:2010/07/12(月) 22:19:47
>>592
固まったのと勘違いしない程度にできるだけ長くだろ

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

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

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


597 :デフォルトの名無しさん:2010/07/12(月) 22:41:21
>>595
ちゃいます
ネットワーク層からトランスポート層まで幅広く受け持っています > socket
ものによっては物理層までも


598 :デフォルトの名無しさん:2010/07/13(火) 20:45:21
DION規制で遅レス(三週間前)になったけど、一応カキコ

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

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

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

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

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

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

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

600 :595:2010/07/13(火) 21:08:19
>>597>>599
お前ら優しいな
ありがとうよ

601 :デフォルトの名無しさん:2010/07/15(木) 21:40:18
ところで、何作っているんですか?

602 :デフォルトの名無しさん:2010/07/15(木) 23:07:53
>>599
元々のバークレイの思想だと 「ソケットは端点定義を抽象化した概念」
ソケット作って, ファイルにコネクトすれば open が出来上がるんだが


603 :デフォルトの名無しさん:2010/07/17(土) 16:27:28
サーバープログラムでもクライアントプログラムも
close()やflush()はした方がいいんですよね?

604 :デフォルトの名無しさん:2010/07/17(土) 17:38:46
>>603
close()は必須。flush()は程度による。

605 :デフォルトの名無しさん:2010/07/17(土) 17:49:27
クライアントですぐ終了するならclose省略可能
サーバーは動作内容によってはcloseしないとfd足りなくなる
どっちにしても同時にいくつもプロセス起動した場合はfd足りなくなる恐れあり
出来るからといってやっていいかどうかは別

606 :603:2010/07/17(土) 18:08:30
>>604-605
参考になったよ
感謝する

607 :デフォルトの名無しさん:2010/07/18(日) 05:47:24
特定の通信手順を使ったデータ送受信アプリをWinsockを使って作っている
のですが対Winだと送受信とも問題ないのですが対Unix系だと送信が極端に
遅くなってしまいます。
Win(自作/他作) <--> Win(自作) 問題なし
Unix系(他作) ---> Win(自作) 問題なし
Unix系(他作) <--- Win(自作) 通信自体は成功するが遅い

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

608 :デフォルトの名無しさん:2010/07/18(日) 06:16:23
2番目と3番目の違いは何?

609 :デフォルトの名無しさん:2010/07/18(日) 07:05:19
まず「特定の通信手順」と「send-send-ack問題」という
>>607が(あるいは>>607の所属する組織が)定義した独自の用語を定義(説明)してくれ。
エスパーはいないから、スレ住人の各自が独自な推測を元に助言をすれば混乱するだけ。

610 :デフォルトの名無しさん:2010/07/18(日) 08:09:58
「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も必読。

611 :デフォルトの名無しさん:2010/07/18(日) 08:25:04
自分で答えを書いてるのでは?www

612 :デフォルトの名無しさん:2010/07/18(日) 08:34:55
モグリは引っ込んでろよ。>>608 != >>610


613 :609:2010/07/18(日) 08:48:03
>>610
おぉー、リンクの紹介ありがとう。知らなかったよ。勉強になった。
WinSockには詳しくないので、モグリと言われてもしかたない。
というか、WinSockにはこんなクソな問題があるの?ポカーンという感想だ。

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

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

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

615 :デフォルトの名無しさん:2010/07/18(日) 09:57:05
サーバ側が他作だからTCP_NODELAYで逃げるのかね。
作り直すならSCTPも面白い。

616 :デフォルトの名無しさん:2010/07/18(日) 11:37:30
暇なのでP2PのDHTを実装しようかなって思っているんですが、
それなりに難易度高いですかね?

617 :デフォルトの名無しさん:2010/07/18(日) 12:10:33
>常に送信し続けて、ACKを並列的に処理すると数十倍の速度になる

ん?

618 :デフォルトの名無しさん:2010/07/18(日) 14:41:05
>TCP自体が効率の悪いプロトコルしてる
>ACK確認が取れるまで次のデータを送信しないからね
このスレって知ったかでデタラメ言う奴多すぎ。

619 :デフォルトの名無しさん:2010/07/18(日) 15:04:51
>>617,618

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

620 :デフォルトの名無しさん:2010/07/18(日) 16:03:50
>>619
違うの?ACK来なかったら再送するでしょ
再送分を送ってる間は結局待ってるようなもんだし
実質的に交互応答になってるんじゃないの?

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

621 :デフォルトの名無しさん:2010/07/18(日) 16:17:23
>>620
「ウインドウサイズ」とか、
その制御の仕方はご存じですか?

622 :デフォルトの名無しさん:2010/07/18(日) 16:33:15
>>620
>それと実装出来なかったとは言ってないTCPより早く出来なかっただけw

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


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

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


624 :デフォルトの名無しさん:2010/07/18(日) 20:23:15
>>623
パケットキャプチャソフトで覗いてやるということはしないのか?

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








625 :609:2010/07/18(日) 22:31:39
>>623
まず、send-send-ack問題も知らずに定義の説明を要求した(>>609の)失礼をお許しください。

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

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

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

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

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

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

(続く)

626 :609:2010/07/18(日) 23:17:07
(>>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を無効にしても無問題であるはずです。

627 :デフォルトの名無しさん:2010/07/18(日) 23:24:36
>>623
>「TCP_NODELAY」は受信側が遅延ACKをやめて即ACKするためのものと思ってましたが、送信側が
>ACK待ちしない為のものだったのですね。

まだ違うよ。

628 :デフォルトの名無しさん:2010/07/19(月) 00:10:48
send-send-ack問題なんてそんなの用語として確立しているものじゃないし、
そんなバグは今時のWinSockでは当然の事ながら解決されてるだろ。
パケットキャプチャもやらないで「たぶん〜問題のせい」ってモグリにも程
があるって感じ。



629 :デフォルトの名無しさん:2010/07/19(月) 00:16:37
納得行くまでやらせて桶

630 :607:2010/07/19(月) 11:18:44
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サイズを調整したり、ログ出力とか
出来るようにしいろいろ試してみたいと思います。
また、みなさんが言われるようにパケットキャプチャを行なえる環境を準備できるか
調整してみたいと思います。

631 :デフォルトの名無しさん:2010/07/19(月) 13:57:03
環境準備って、フリーソフトでいいがな

632 :デフォルトの名無しさん:2010/07/20(火) 21:55:42
ソケットディスクリプタはソケットを識別する物ってことで、おk?

633 :デフォルトの名無しさん:2010/07/21(水) 10:19:58
ファイルディスクリプタみたいなもの

634 :デフォルトの名無しさん:2010/07/21(水) 11:06:20
同じものみたいな

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

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

636 :デフォルトの名無しさん:2010/07/21(水) 18:12:05
メールは世の中に適当実装があふれてるから
それ全部対応しないといけないし勉強とかが目的ならあまりお勧めしない
何年も掛かる

637 :デフォルトの名無しさん:2010/07/21(水) 18:20:02
>>636
指示されたエンコードで可視可したら文字化けトラップ ですな

638 :デフォルトの名無しさん:2010/07/21(水) 20:33:38
>>635
> http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html

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

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


639 :デフォルトの名無しさん:2010/07/22(木) 08:33:21
>>637
半角カナを平気で使うリテラシの無いユーザもいるから、メーラの実装は大変だよね

640 :デフォルトの名無しさん:2010/07/22(木) 14:20:18
WinsockとUDPを使った送信プログラムを作成しています。
ある異常系の試験を行っていて気がついたのですが、
サーバーへの接続後、サーバー側のLANケーブルを抜いた場合の挙動が
OSによって異なることが分かりました。

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

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

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

641 :デフォルトの名無しさん:2010/07/22(木) 15:04:11
>>640
vistaからarpの挙動が変わったようだけど。

642 :デフォルトの名無しさん:2010/07/22(木) 15:19:11
>>641
レスありがとうございます

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

643 :デフォルトの名無しさん:2010/07/22(木) 15:32:07
>>639
本文に使用する分には問題なくね?

644 :デフォルトの名無しさん:2010/07/22(木) 15:36:53
「問題なくね?」とか書く30代がきもいんですが。

645 :デフォルトの名無しさん:2010/07/22(木) 15:49:46
本文に半角は問題ありますが、人格を責めるような書き込みがきもいです。

646 :デフォルトの名無しさん:2010/07/22(木) 17:48:33
「きもい」なんて表明しないと気が済まない人がきもいんですが。

647 :デフォルトの名無しさん:2010/07/22(木) 19:51:43
>>640
> 具体的にはWindowsXPではsendtoでデータを送信しても即座に処理を戻すのですが
> (GetTickCountでとると0ms)
間に何が入っているかにもよると思うんだが


648 :デフォルトの名無しさん:2010/07/22(木) 20:41:44
>>640
別々のネットワークに置いても、挙動は同じなの?
っと。

649 :デフォルトの名無しさん:2010/07/22(木) 23:08:24
はぁ?

650 :デフォルトの名無しさん:2010/07/23(金) 12:54:05
低レベルなパケットのやり取りをすると
いくら待機を制御しても連続してパケットがくるとCPU使用率が100%になる
本来ならカーネルがやってるからCPU使用率には反映されないだけなんだろうけど
ユーザーサイドのアプリケーションだと出てくる
結局は同じことだとしても気持ちが悪い
CPU使用率を下げる方法ってあるの?

651 :デフォルトの名無しさん:2010/07/23(金) 13:02:04
>>650
カーネル、ユーザランド間の状態遷移。イベント通知、全然同じじゃない。

652 :デフォルトの名無しさん:2010/07/23(金) 13:25:39
>本来ならカーネルがやってるからCPU使用率には反映されないだけなんだろうけど

???

653 :デフォルトの名無しさん:2010/07/23(金) 13:50:49
>>652
パケットの並び替えとか再送処理とかをカーネルモードドライバがやってて
ドライバのCPU使用率は画面には出てこない
小さいパケットをループで回して処理するようなことをユーザーアプリでやったら
CPU使用率に反映されて100%になる
カーネルレベルでやろうがユーザーレベルでやろうが同じことをやろうとしたら
リソースコストは同じだけども、見た目が悪いのでCPU使用率に反映させない
方法はないものだろうか


654 :デフォルトの名無しさん:2010/07/23(金) 14:13:56
sleepはさめばいいんじゃね

655 :デフォルトの名無しさん:2010/07/23(金) 14:30:34
>>654
sleepしたら通信が遅くなるでしょ

656 :デフォルトの名無しさん:2010/07/23(金) 14:42:25
> 連続してパケットがくるとCPU使用率が100%になる
連続してパケットが来たときに、自前処理やってるんだから100%になっても不思議じゃないよね。
その処理分を「CPU使用率」から除外したいってこと?

無理なんじゃね?

657 :デフォルトの名無しさん:2010/07/23(金) 14:46:59
>>653
>カーネルレベルでやろうがユーザーレベルでやろうが同じことをやろうとしたら
>リソースコストは同じだけども

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

658 :デフォルトの名無しさん:2010/07/23(金) 14:55:03
専用のドライバ書くとかw


659 :デフォルトの名無しさん:2010/07/23(金) 14:59:37
え、これってネットワークが鬼畜に速いかPCが遅すぎるとかいう話?
それともリアルタイムで糞重いエンコーディングとか画像処理系のフィルタリングかけてるとか?

だったらもっと速いPC買おうぜ
要するに処理能力が足りてないんだよ

660 :デフォルトの名無しさん:2010/07/23(金) 15:11:24
>>659
UDPデータが連続して来るのにネットワーク速度はあんまり関係ないよね
ローカルLAN同士の通信で1000バイトやそこらのパケットの連続を
ループでまわすと処理の大小はあんまり関係ないと思うのだけど

661 :デフォルトの名無しさん:2010/07/23(金) 15:57:32
sleep っつーか yield 挟むだけでも遅くなるような処理なの?
そんな膨大なデータやりとりするなら、しゃーないんじゃないかなあ


662 :デフォルトの名無しさん:2010/07/23(金) 15:58:14
え?UDPの話なの?

663 :デフォルトの名無しさん:2010/07/23(金) 16:02:18
UDPでsocket使ったユーザレベルアプリがCPU使用率100%になるって話?

664 :デフォルトの名無しさん:2010/07/23(金) 17:06:42
UDP受信ね

665 :デフォルトの名無しさん:2010/07/23(金) 17:32:28
なんかこの話題振ってる人不愉快

666 :デフォルトの名無しさん:2010/07/23(金) 18:13:05
>>653
CPU使用率って誰が管理してんの?

667 :デフォルトの名無しさん:2010/07/23(金) 18:17:58
単に非blockモードでreceiveを連続的に発行しているから
CPU使用率が100%になっているだけだと推測。
selectあるいは(Win32の)イベントオブジェクトで
UDP受信を非同期処理で実現していれば、
(一般的には)CPU使用率が100%になることはありえない。


668 :デフォルトの名無しさん:2010/07/23(金) 18:25:57
>653
>>見た目が悪いのでCPU使用率に反映させない方法はないものだろうか

 今日の晩ご飯はカレーライスがいい、カレーライスじゃなきゃ絶対にイヤダ!!

と言っているガキの戯言にしか聞こえない。あるいは、

 中間試験の英語と数学で赤点をとってしまった。母親に知られるとやばいので、
 それを隠し通せる方法はないものだろうか?

でもいい。質問の内容がプログラミング相談室向けでは無い。
お子様向け人生相談室に合う話題だ。

669 :デフォルトの名無しさん:2010/07/23(金) 18:40:53
>>667
もちろんロックを実装して何も無い時にCPU負荷が上がらないようにしてるけど
データベースの1レコードを1つのパケットにして何十件かをまとめて送るんだけど
もちろん転送効率を落としたくないから可能な限り早く発送して再送をする
ローカル環境では50ミリ秒前後の遅延がロスが少ない感じだけど
この頻度でも受信側はループして処理すると100%になるよ

670 :デフォルトの名無しさん:2010/07/23(金) 18:53:17
>>669
プラットフォームはWindows(WinSock)でいいのかな?以下、Yesとして答えるよ。

>>もちろんロックを実装して何も無い時にCPU負荷が上がらないようにしてるけど
ロックというのはWin32 APIのクリチカルセクションのことかな?
これは資源の排他制御に使う操作だから、これをループに組み込めばCPUを無駄に消費するのは当然。
>>667で書いたように、selectあるいはイベントオブジェクトで実装する必要がある。

671 :デフォルトの名無しさん:2010/07/23(金) 19:19:58
>>667はそういう意味で言ってないよ
言語はC#でWaitHandleというものがある
恐らくWaitSingleObject APIをラップしたものだろうと思う
確かにコストは大きいけどCPU使用率に極端に影響するほどのコストではないと思うけどな

672 :デフォルトの名無しさん:2010/07/23(金) 19:21:52
どっちかというと受信したデータを加工する作業が負担になってるし
これは省略出来ない処理なんでどうしようもない

673 : ◆0uxK91AxII :2010/07/23(金) 21:30:57
>>650
kernelでCPUを喰っているなら、HWを買い換える。
userでなら、糞なprogramを書き換える。

674 :デフォルトの名無しさん:2010/07/27(火) 12:39:17
Windows のコマンドラインアプリで netsh ってあるけどこれってシスコCLIみたいだなーと思ったら、まんま移植したものっぽいね。
netsh ってWindowsでサーバー構築してる人が使うものなんですか?

675 :デフォルトの名無しさん:2010/07/27(火) 12:53:44
べっ、別にサーバー以外で使ってもいいんだからねっ

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

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

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