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

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

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

1 :デフォルトの名無しさん:2006/05/30(火) 08:16:00
主にソケットに関しての質疑応答スレッドです。

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

前スレ
ネットワークプログラミング相談室 Port16
http://pc8.2ch.net/test/read.cgi/tech/1136005644/

2 :デフォルトの名無しさん:2006/05/30(火) 08:17:00
過去スレ:
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 ttp://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 ttp://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 ttp://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 ttp://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 ttp://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 ttp://pc.2ch.net/tech/kako/970/970344582.html

まとめ ttp://makimo.to/cgi-bin/search/search.cgi?q=%83l%83b%83g%83%8F%81%5B%83N%81%40%91%8A%92k%8E%BA&andor=AND&sf=0&H=ikenai&D=tech&shw=2000


3 :デフォルトの名無しさん:2006/05/30(火) 08:18:46
図書コーナー:
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 :デフォルトの名無しさん:2006/05/30(火) 08:19:45
マスタリング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 :デフォルトの名無しさん:2006/05/30(火) 08:20:17
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/rfc_ja/2616/rfc2616_ja.html
IANA Well known port numbers
 http://www.iana.org/assignments/port-numbers
★プログラミング
C10K ヘヴィーロードサーバ
 http://www.kegel.com/c10k.html
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/


6 :デフォルトの名無しさん:2006/05/30(火) 08:20:53
★ツール類
ethereal - http://www.ethereal.com/
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


7 :デフォルトの名無しさん:2006/05/30(火) 08:27:53
>>1
otsu

8 :デフォルトの名無しさん:2006/05/30(火) 08:32:16
前スレだが、頭に数字の逆引き設定してると不具合起こす鯖プログラムって有るの?
面白いから、数字だけのホスト名付けてみるかな(w

9 :デフォルトの名無しさん:2006/05/30(火) 11:12:18
>>8
127.0.0.1 なんてのが逆引きで得られたらアレだよなぁ。

10 :デフォルトの名無しさん:2006/05/30(火) 11:31:07
数字だけのホスト名とか無理でしょ

11 :デフォルトの名無しさん:2006/05/30(火) 16:39:35
はっはっは。おもしろい冗談だ。

12 :デフォルトの名無しさん:2006/05/30(火) 21:51:35
O2

13 :デフォルトの名無しさん:2006/05/30(火) 21:53:42
ttp://3.14159265358979323846264338327950288419716939937510.com/


14 :デフォルトの名無しさん:2006/05/30(火) 22:16:02
先頭が数字かで判断してるなら、↑だけでなく
http://2ch.netも逆引き出来なそうだけど。

15 :デフォルトの名無しさん:2006/05/30(火) 22:58:19
「3」がホスト名w

16 :デフォルトの名無しさん:2006/05/31(水) 00:40:45
2ch.netじゃなくてwww.2ch.netだし

17 :デフォルトの名無しさん:2006/05/31(水) 02:02:07
LSP (Layered Service Provider) について詳しい方、
使い方をご教示ください。

18 :前スレの988:2006/05/31(水) 02:18:18
>>最初の文字が数値ならIPアドレスの文字列
>>それ以外ならホスト名
これ嘘でしたwwwwすまんwww

↓たぶんこれが正解
文字列が数値かピリオドのみで構成されてるならIPアドレスの文字列
それ以外ならホスト名

19 :デフォルトの名無しさん:2006/05/31(水) 02:29:54
適当過ぎwww

20 :デフォルトの名無しさん:2006/05/31(水) 03:00:49
>>16
はあ?

21 :デフォルトの名無しさん:2006/05/31(水) 03:34:17
適当な返答止めてくれ無いかな、
バグがうまれたらどうすんだよ

22 :デフォルトの名無しさん:2006/05/31(水) 08:17:15
2chでの情報を鵜呑みにして
バグ生まれちゃ困るな。

23 :デフォルトの名無しさん:2006/05/31(水) 13:03:54
>>18
それじゃ 1.2.3.4.5.6 なんてのも IP アドレスになっちゃうじゃん。
・IP アドレスとして解釈可能なら、IP アドレスとして解釈できる。
・そうでないなら、IPアドレスとして解釈できない。
これくらいしか言えないだろ・・

24 :デフォルトの名無しさん:2006/05/31(水) 13:18:09
>>23
馬鹿は黙っててくれ

25 :デフォルトの名無しさん:2006/05/31(水) 13:28:26
>>24
貴様こそ黙れよ。

現状既に a a.b a.b.c a.b.c.d の IPv4 4形式に加えて IPv6 なんてのも
あるわけで、その環境(やアプリの仕様)に即して何が「IPアドレスとして
解釈可能」かも変るだろ。

非「IPアドレス」が即ホスト名やDQDNなわけでも無いし。

26 :デフォルトの名無しさん:2006/05/31(水) 13:31:06
>>25
馬鹿は黙っててくれ

27 :デフォルトの名無しさん:2006/05/31(水) 13:33:32
元の質問した人のために、
この辺で識者が正解を書いてください。

28 :デフォルトの名無しさん:2006/05/31(水) 15:33:04
実はMACアドレスも有効だったりする


29 :デフォルトの名無しさん:2006/05/31(水) 23:39:41
ping 127.1
ping 127.0.1
ping 0x7f000001
ping 017700000001
ping 2130706433

30 :デフォルトの名無しさん:2006/05/31(水) 23:53:10
RFC3986にhost部がIPアドレスの場合のABNFが載ってるからそれ参考にしろ
それ以外の形式でもIPアドレスとして認識される場合があるけど
(>>29みたいに)リゾルバ依存

31 :デフォルトの名無しさん:2006/06/02(金) 00:33:15
教えてください。
WINNT4.0のPCでソケット通信中にICMP(type3 code1)ホスト到達不能を
受信した際、ソケット伝送プログラムにそのエラーが通知されることなく、
その後なにごともなく通信が継続されていました。
SVR4ベースのシステムの場合、同じくICMP(type3 code1)を受信した時点で
ソケットをクローズしてしまいます。
これはOSに依存する仕様なのでしょうか?
要はSVR4ベースのシステムもWINNT4.0の場合と同じように
即断しないようにしたいのですが。

32 :デフォルトの名無しさん:2006/06/02(金) 16:21:37
javaとPerlで 同じ ストリーミングデータにアクセスした場合、
java と perl で取得するパケットデータが異なるっていうのはどういう現象かわかる人いますか?

javaは SocketChannel
perlはsocket()
で接続しています

33 :デフォルトの名無しさん:2006/06/02(金) 16:45:13
>>31
そのケース、XP だと ECONNRESET で切れるよ。
setsockopt でオプションを指定すればNT4と同じ動作にもできるけど。

34 :デフォルトの名無しさん:2006/06/02(金) 17:13:01
>>27
前スレ>>996のgetaddrinfoが正解

どうしてもAF_INET*依存にしたければ、
inet_pton()でも使って。

35 :デフォルトの名無しさん:2006/06/03(土) 00:10:58
>>32
日本語大丈夫?

どういう現象って、「取得するパケットデータが異なる」って言う現象だろ。

原因はなんかバグってんじゃねーのぐらいしかわからんが。

36 :デフォルトの名無しさん:2006/06/03(土) 00:23:11
getaddrinfoは非同期版が無いのがダメ

37 :デフォルトの名無しさん:2006/06/03(土) 00:34:56
getaddrinfoって、Win2Kで使えるの?

38 :デフォルトの名無しさん:2006/06/03(土) 10:18:07
>>35

バグがあることを「原因」と呼ぶと自分の責任になるだろ?

「現象」と呼ぶことによって責任を回避しているのさ

そんな >>32 の意図を読み取れないおまえこそ日本語大丈夫か?



39 :31:2006/06/03(土) 11:09:17
>>33
どうもありがとうございます。
win、unix、Linux、さらにそれぞれのバージョンや系統によって
ICMP(type3 code1)を受けた時のうごきはデフォで違っていて
それはおそらくどのOSでもソケットのオプションによって変えられる、
という感じなんでしょうか?
>>setsockopt でオプションを指定すればNT4と同じ動作にもできるけど。
ちなみにこれはXPのことなのでしょうか?それともSVR4のことですか?


40 :デフォルトの名無しさん:2006/06/03(土) 11:42:14
>>31
ICMP_DEST_UNREACHでも接続を維持するというのは、
極めて異常な処理方針で、問題も起きやすいので、
どのOSでも出来ることを期待しない方がいいです。

再接続を試みてはどうでしょうか?

ICMP_FILTERソケットオプションでicmpパケットを無視できるUNIXもありますが。

> その後なにごともなく通信が継続されていました。

こっちの方がbugでしょう。(MS的には仕様)

41 :デフォルトの名無しさん:2006/06/03(土) 11:47:47
getsockopt を vb6から呼び出して、SENDとRECVのタイムアウト値をとる方法おしえてくらはい
いろんな型でやってみたけどとれないくさい


42 :デフォルトの名無しさん:2006/06/03(土) 14:25:47
>>38
> 「現象」と呼ぶことによって責任を回避しているのさ

きっといいこと言ったとか思ってるんだろうなぁ。
そっとしておいてやろう。

>>39
て言うか、なんでそんな ICMP 返ってくるかを調べるほうが先じゃないのか?

>>41
> いろんな型でやってみたけどとれないくさい

どういう風にやったかを書かないのは、おじいちゃんの遺言か?

43 :デフォルトの名無しさん:2006/06/03(土) 14:56:33
Public Declare Function getsockopt Lib "wsock32.dll" _
(ByVal s As Long, ByVal level As Long, ByVal optname As Long, optval As Any, optlen As Long) As Long

optval As Any の受けを、基本型すべてで、byref、byval全部試した。
マイクロソフトに利用方法がある
ttp://support.microsoft.com/default.aspx?scid=kb%3Bja%3B237688

追加オプションのうち、&H1003〜&H1006をわざとはずしている?
' Additional options.
Const SO_SNDBUF = &H1001& ' Send buffer size.
Const SO_RCVBUF = &H1002& ' Receive buffer size.
Const SO_ERROR = &H1007& ' Get error status and clear.
Const SO_TYPE = &H1008& ' Get socket type - READ-ONLY.

以下が無い。
Const SO_SNDLOWAT = &H1003
Const SO_RCVLOWAT = &H1004
Const SO_SNDTIMEO = &H1005
Const SO_RCVTIMEO = &H1006

でも、Winsock.hにはある。

44 :デフォルトの名無しさん:2006/06/03(土) 16:55:59
>>42
> どういう風にやったかを書かないのは、おじいちゃんの遺言か?

いい感じにイヤミっぽいので、イヤミフォルダに保存した。

45 :初心者:2006/06/04(日) 12:27:48
Windos環境で、DNATやSNATを行う方法はありますか?
または、Windows環境でDNATやSNATを行うプログラムって作れますか?


46 :デフォルトの名無しさん:2006/06/04(日) 12:39:15
>>45
ソース読め
http://osswin.sourceforge.net/#firewall

47 :デフォルトの名無しさん:2006/06/04(日) 13:06:23
http://etc3.2ch.net/test/read.cgi/entrance/1149248659/56


48 :デフォルトの名無しさん:2006/06/04(日) 15:41:29
おまいら本当にapi知らない香具師ばっかりだなあ。
これじゃあネットワーク関連でバグ出まくりなのは当たり前だわ。

49 :デフォルトの名無しさん:2006/06/04(日) 15:50:25
>>48
わかるやつはここに相談しないとおもう


50 :デフォルトの名無しさん:2006/06/04(日) 21:59:26
ソケットによるTCP/IP通信プログラムを
これから書くことになるのですが、
どんな勉強手順をとれば効率良く
マスターできますか?

おそらく多量で難解なRFC文書を読むことでは
ないように思います。

やるのはhttps(SSL+認証付)のSOAP応用です。
開発はVxWorksベースです。
もっぱら組み込みハード制御をやってきたので
Windowsアプリは全然組めません。
C、C++他は一通り組めます。


51 :デフォルトの名無しさん:2006/06/04(日) 22:18:21
SOAPのライブラリがあるなら、そのAPIの勉強しなよ。
まさか全部自作ってことはないよね。

52 :デフォルトの名無しさん:2006/06/04(日) 22:51:39
>>51
使っているVxWorksにはSOAPのライブラリ関数はありません。
SSLはOpenSSLを使った香具師が関連会社にいますが、ノウハウは不明。
たわしは、ソケット関数自体使った経験が全くないので、どこからどういう
順番(手順)で高速に勉強するか、まずそこから知りたいのです。

http://www.sist.ac.jp/~suganuma/cpp/4-bu/19-sho/19-sho.htm#mokuji
を読み始めましたが、完全理解はできていないレベルです。


53 :デフォルトの名無しさん:2006/06/04(日) 22:58:08
OpenSSL以外は全部作ることが前提ですか?

54 :デフォルトの名無しさん:2006/06/04(日) 23:22:40
>>52
これは動かんのか?
http://www.windriver.com/japan/products/windmanage_xml-soap/index.html

55 :デフォルトの名無しさん:2006/06/04(日) 23:24:17
まあソースかライブラリ買うか自分で作るかだね。
自分で作るくらいならVxWorksのメリット無いよ。linuxにしといたら?

組み込みだからこそ、10年放置しても問題ない様にRFCを熟読してきちんと仕様を満たす実装で納品して欲しい。

56 :デフォルトの名無しさん:2006/06/04(日) 23:24:46
>>53
VxWorksのTCPソケット関数が使える環境です。
その上位の応用レイヤは作らねばなりません。
OpenSSLもコンパイルできるかどうかも不明です。
たわしはそういうレベルの初心者です。


57 :デフォルトの名無しさん:2006/06/04(日) 23:31:35
>>54
そのミドルウェアは知りませんでした。
明日、今のVxWorksのVersionで動くか調べてみます。

real time linux の環境では、
GPLつきソフトを使わないことが条件です。

製品のソース開示は出来ないので、それ故、訴えられる可能性があるためです。


58 :デフォルトの名無しさん:2006/06/05(月) 00:14:35
>>56
いや、SSLやSOAPを実装するのはかなりの腕がないと無理。
なんちゃってになって、トラブル続出するの可能性大。

RFC読むことないって事で、それはそれでいいんだけど、
SSLとSOAPの関連仕様書はかなり膨大。(RFCになっているものもある)


59 :デフォルトの名無しさん:2006/06/05(月) 01:08:07
winsock2.hで、
typedef UINT_PTR SOCKET;
typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
要はunsinged intでしょ?
で、SOCKET_ERRORは
#define SOCKET_ERROR (-1)
-1ってことでしょ?
SOCKET s = socket(...);
で、sはunsigned intなのにエラーの場合-1が代入されるってこれOKなの?

60 :デフォルトの名無しさん:2006/06/05(月) 01:51:43
>>59
windowsのAPIってそんなんばっかりやん。

61 :デフォルトの名無しさん:2006/06/05(月) 02:05:28
正常なとき 0 返してたりするしな

62 :デフォルトの名無しさん:2006/06/05(月) 02:46:38
ソース開示したくなければなおさら自分で作るか買ってくるしか無いな。
明らかにスキルが足りないと思う。仕事なら違約金払ってでも断るべきだよ。

63 :デフォルトの名無しさん:2006/06/05(月) 08:12:15
OpenSSLは使っても開示する必要がない。

64 :デフォルトの名無しさん:2006/06/05(月) 10:42:56
どうせopenssl載せるなら同じ作者のOpenBSDだかでも載せたら?
ちなみに作者のtheoはかなりのDQNだよ。qmailの作者レベル。

65 :デフォルトの名無しさん:2006/06/05(月) 11:12:39
>同じ作者のOpenBSD
>同じ作者のOpenBSD
>同じ作者のOpenBSD

66 :デフォルトの名無しさん:2006/06/05(月) 13:14:41
>>39
>>>setsockopt でオプションを指定すればNT4と同じ動作にもできるけど。
>ちなみにこれはXPのことなのでしょうか?それともSVR4のことですか?
これは XP (たぶん Windows Server 2003 も) です。

>>42
>て言うか、なんでそんな ICMP 返ってくるかを調べるほうが先じゃないのか?

漏れがこれ経験したのはインターネット上の不足低多数の数百箇所程度の
クライアント向けにサーバを動かしているとき。一日数件程度発生してました。
経路上のどっかで何かがあったんでしょう。

ちなみに XP で UDP ソケット使っててこれ食らうと、OS 側スタックのどこかが
unreachable を覚えてしまって、それ以降の send も失敗します(オプションで
回避可能)。

67 :デフォルトの名無しさん:2006/06/05(月) 16:32:22
オンラインゲーム鯖でDoS喰らうよく有る攻撃方法の一つだな。

68 :デフォルトの名無しさん:2006/06/05(月) 17:18:40
その辺りは、いちいちアプリで相手にしてられないから、
ipfw, ipfilter辺りで処理するのが定石かと。

69 :デフォルトの名無しさん:2006/06/05(月) 19:57:42
不足低多数ってどういうtypoだよw

70 :デフォルトの名無しさん:2006/06/05(月) 22:13:21
不特定多数: ふとくていたすう: futokuteitasuu
不足低多数: ふそくていたすう: fusokuteitasuu

一文字ごときの typo にいちいち突っ込むなよ。

71 :デフォルトの名無しさん:2006/06/06(火) 02:19:51
太くてたまらない

72 :デフォルトの名無しさん:2006/06/07(水) 08:03:56
他のプロセスのTCPコネクションを切断したいのですが
どのような方法がありますか?

73 :デフォルトの名無しさん:2006/06/07(水) 14:10:49
>>72
Winny に干渉するのが目的なら、先方の host 指定して
デタラメなホストルートでも切れば良いと思う。

74 :デフォルトの名無しさん:2006/06/07(水) 15:05:13
>>72
そのプロセスを殺す。

75 :デフォルトの名無しさん:2006/06/07(水) 15:45:24
>>73
Winnyじゃないよー

>>74
全部切れたら困っちゃう

76 :デフォルトの名無しさん:2006/06/07(水) 23:13:32
て言うか、何のためにそんなことしたいんだよ。

77 :デフォルトの名無しさん:2006/06/08(木) 00:13:34
目的はいいけど状況とOSくらいは書いてくれないと…

78 :デフォルトの名無しさん:2006/06/08(木) 09:28:23
OSはWindows2000/XPでOKです。

RSTパケットを送り付けたいです。

79 :デフォルトの名無しさん:2006/06/08(木) 09:32:56
FINのほうがいいかなー

80 :デフォルトの名無しさん:2006/06/10(土) 08:20:55
arp投げまくるのでもよさそう

81 :デフォルトの名無しさん:2006/06/10(土) 09:32:26
>>80
> 全部切れたら困っちゃう

82 :デフォルトの名無しさん:2006/06/11(日) 15:08:56
質問があるのですが
ルータ等に実装されているのIPマスカレード機能をプログラムで
実装するにはどんな関数を使えばいいのでしょうか?
リバースプロキシみたいではなくsrc-dis間で総コネクション数は1つで
済ませたいのです。
環境:POSIX系OS

83 :デフォルトの名無しさん:2006/06/11(日) 15:18:52
IPmasqの前にただのルーター実装したことはあるの?

84 :デフォルトの名無しさん:2006/06/11(日) 16:25:46
>>83
ルータ実装の方が遙かに難しい気がするのですが・・
ただOS依存のネットワークAPIプログラミングで、送られてきたパケットを
IPレベルで見てsrc,dscのアドレス,ポートを書き換えて
変換したパケットを再び送信する方法ってないのかなと思ったのですが
もしかしてNICドライバ依存とかの話になってしまうのでしょうか?

85 :デフォルトの名無しさん:2006/06/11(日) 18:01:54
>OS依存のネットワークAPIプログラミングで、送られてきたパケットを
>IPレベルで見てsrc,dscのアドレス,ポートを書き換えて
>変換したパケットを再び送信する方法

あるよ

86 :デフォルトの名無しさん:2006/06/11(日) 18:10:39
あるね。NIC のドライバには依存しないと思う。

87 :デフォルトの名無しさん:2006/06/11(日) 18:53:50
>>85-86
その方法に関係する関数名、キーワードだけでも教えていただけないでしょうか

88 :デフォルトの名無しさん:2006/06/11(日) 18:56:26
raw
promisc

89 :デフォルトの名無しさん:2006/06/11(日) 19:30:58
>>88
ありがとうございます
RAWソケットを作成することで出来るのですね

90 :デフォルトの名無しさん:2006/06/11(日) 20:19:16
>>82
> src-dis間で総コネクション数は1つで済ませたいのです。

っていうのはどういうこと?


91 :デフォルトの名無しさん:2006/06/11(日) 20:47:45
IPマスカレードならクライアントからサーバ、でコネクション数1
リバースプロキシならクライアントから中継ノード、
中継ノードからサーバ、でコネクション数2
になるという意味です。

92 :デフォルトの名無しさん:2006/06/11(日) 21:31:36
そうか orz

UDPは無視なの?

93 :デフォルトの名無しさん:2006/06/11(日) 21:51:33
UDPは無視というか3層レベルで中継させるのではなく
2層レベルで中継させたいということを説明したいがために
TCPっぽい事象に限定したような話になってしまいました。
厳密には3層の一部(ポート番号)も関係するのですが・・
言葉足らずな質問で混乱させてしまいすいませんでした。

94 :デフォルトの名無しさん:2006/06/13(火) 11:52:36
HTTPDヘッダについての質問です

Windows Media Player の吐き出すHTTPDヘッダが以下のようになっているのですが

POST / HTTP/1.0
Accept: */*
User-Agent: NSPlayer/10.0.0.3802
Host: siren-vip.ddo.jp
Pragma: xClientGUID={3300AD50-2C39-46c0-AE0A-D884CE1C993C}
X-Accept-Authentication: Negotiate, NTLM, Digest, Basic
Pragma: client-id=3081659744
Pragma: client-lag=0
Pragma: stream-switch-count=1
Pragma: stream-switch-entry=ffff:2:1
Content-Length: 0

これはどのような情報かわかる人いらっしゃいますでしょうか?
もしくは、このようなヘッダ情報を説明しているページがあればご教授ください

95 :デフォルトの名無しさん:2006/06/13(火) 14:36:30
>>3の本と>>5のRFCのHTTPを。

'D'は余分ね。

96 :デフォルトの名無しさん:2006/06/14(水) 20:30:14
windowsXP vc++6.0
TCPIP Socket通信にて
パケットを1バイトずつ受信して特定キーを受信したら
そこまでを1区切りのデータとして扱う処理で、
パケットで特定キーを受信しなかった場合
データを保持しておき、次のパケットで特定キーを
受信したら保持したデータを合わせて1区切りのデータと
して扱うという処理を追加したいのですが
どうコードを書けばいいかわかりません。。。
どなたか教えてくださいませんか?

97 :デフォルトの名無しさん:2006/06/14(水) 21:20:46
stdioか、iostream使えよ。

98 :デフォルトの名無しさん:2006/06/14(水) 21:59:20
ここで議論できるレベルに到達するに建設的な書籍を挙げていただきたい。

99 :デフォルトの名無しさん:2006/06/14(水) 22:10:37
>>3


100 :デフォルトの名無しさん:2006/06/14(水) 22:13:06

ひとそれぞれだろうけど参考までに

ttp://www.amazon.co.jp/gp/product/4274065847/
ttp://www.amazon.co.jp/gp/product/4274065820/


101 :デフォルトの名無しさん:2006/06/14(水) 22:26:47

こんばんは。
インターネットで有害なサイトを指定しておいて見れなくするソフトありますよね。
あれはどうやってブラウザからアドレスを取得しているんですか?
仕組みだけでいいので教えてください。よろしくお願いします。

102 :デフォルトの名無しさん:2006/06/14(水) 22:36:51
ブラウザからアドレスを取得している訳ではない

103 :デフォルトの名無しさん:2006/06/14(水) 23:25:26
どこかに情報置いといて、定期的に更新するだけ。
つーかプログラミングの話じゃないね。パソコン初心者板にでも逝け。

ICMPを捨てたら捨てたでいろいろ問題有るよ。

104 :デフォルトの名無しさん:2006/06/15(木) 19:12:11
ここにいる人は通信系の会社で働いてる人?

105 :デフォルトの名無しさん:2006/06/16(金) 00:11:50
違う

106 :デフォルトの名無しさん:2006/06/16(金) 01:44:43
そうだったけど今は違う

107 :デフォルトの名無しさん:2006/06/16(金) 03:43:14
むしろ通信屋に苦労させられてる香具師とか、通信屋を憎んでる香具師のほうが多いと思う。
パケット捨てるんじゃねーって(w
まあそのくせルータ屋として通信屋に納入するときは、大量にパケット落ちするような糞製品を作ってる悪寒(w

108 :デフォルトの名無しさん:2006/06/16(金) 12:34:47
まだ学生だったりする

109 :デフォルトの名無しさん:2006/06/16(金) 19:57:56
OS WinXP Pro SP2
IDE VS .net 2003
言語 C++
で Winsock を使っているのですが、ネットワークプログラムにおいて
実数型 (float) を送信する際はどのようにするのが一般的でしょうか ?
htonl( *(u_long*)&data ); とするのは強引ですか ?

110 :デフォルトの名無しさん:2006/06/16(金) 22:55:44
>>109
そういうときは、プロトコルを先に考える。
で、
・コンパクトで高速なバイナリ形式にする
・IEEE の短精度実数形式を用いる

と決めて、x86 の float は IEEE に準拠してるよね、
ということで安心してそのコードを実装として使う。

111 :デフォルトの名無しさん:2006/06/16(金) 23:02:34
バイナリ時のエンディアンをどうするかという話に見えるが

112 :デフォルトの名無しさん:2006/06/16(金) 23:03:41
文字列でいいだろ
どんな精度だってOKさ

113 :デフォルトの名無しさん:2006/06/16(金) 23:14:14
>>109
量が多い時は、
まず最初に相手とバイトオーダーのネゴをして、
違う場合のみバイトスワップをする。
同じ時はそのまま送る。

という方法もある。

114 :109:2006/06/17(土) 00:01:24
>>110-113
一応変換して送っておこうと思っていました。
変換は >>109 で大丈夫ということなので、ありがとうございました。

115 :デフォルトの名無しさん:2006/06/17(土) 00:36:25
u_longを直接書くのは止めてtypedefにしといた方がいいと思う。
すぐに64bitなWinの時代だし。

116 :デフォルトの名無しさん:2006/06/17(土) 03:32:40
>>115
そういうこと詳しく解説してるサイトない?

117 :デフォルトの名無しさん:2006/06/17(土) 04:39:19
単に64bit環境への対応ってならここ見ればいい。
http://docs.sun.com/app/docs/doc/819-0389

Windowsだとuintptr_tがUINT_PTRだったりと名前が違ったりする(これがSOCKET型)が
留意点は基本的に同じ。

118 :デフォルトの名無しさん:2006/06/17(土) 14:55:56
さんくす。読む。

119 :デフォルトの名無しさん:2006/06/17(土) 21:30:06
WinSock 2.0でノンブロッキング・ソケットを使っているのですが、
WSAEventSelect関数で待機していると、
イベントオブジェクトがシグナル状態となるのに
イベントフラグを見ると何も発生していない(ゼロ)という現象が発生し悩んでいます。
下のサイトにも同じ投稿があったのですが、
この現象は無視してもいいのでしょうか?
ttp://forums.belution.com/ja/vc/000/308/18.shtml

120 :デフォルトの名無しさん:2006/06/17(土) 21:39:40
今日からWinSock使ってネットワークプログラミングをやろうとしてるんですが
ネットワークに関する知識はどれくらい必要でしょうか?
それと、特別な通信環境を用意する必要はありますか?
サーバープログラムではIPアドレスなどを記述するようですが、
IPアドレスは固定できるのですか?

121 :デフォルトの名無しさん:2006/06/18(日) 00:53:22
>>120
最低でも>>1くらいは読みましたか?

122 :デフォルトの名無しさん:2006/06/18(日) 01:03:35
とりあえず一冊本買って読めw

123 :デフォルトの名無しさん:2006/06/18(日) 01:11:12
>>119
> 下のサイトにも同じ投稿があったのですが、

そのサイトは自己解決してるみたいだが…。

124 :デフォルトの名無しさん:2006/06/18(日) 01:46:45
ネットワークの知識が全くないのですが、そういう場合はどの本を読めばいいですか?
基本的なことしか書いてない本でもいいので、馬鹿でも理解できる本を教えてください

125 :デフォルトの名無しさん:2006/06/18(日) 01:51:43
winsockでhttpクライアントを作っているのですが
ページを次々にGETしにいく場合
socket() -> connect() -> send() -> recv() -> send() -> recv() ->
send() -> recv() -> send() -> recv() -> closesocket()
てな感じにやるのかなぁと思ってやってみたのですがうまく動きませんでした。

socket() -> connect() -> send() -> recv() -> closesocket() ->
socket() -> connect() -> send() -> recv() -> closesocket() ->
socket() -> connect() -> send() -> recv() -> closesocket()
てやるとうまく動くんですけど これが正解なんですか?

126 :デフォルトの名無しさん:2006/06/18(日) 02:30:46
HTTP/1.1
Keep-Alive

127 :デフォルトの名無しさん:2006/06/18(日) 02:37:55
>>125
RFCはお読みになられましたか?

128 :デフォルトの名無しさん:2006/06/18(日) 08:32:20
>>124
テンプレ読んで。

129 :125:2006/06/18(日) 09:11:38
>>126-127
レスありがとうございます

RFC 2068 Hypertext Transfer Protocol HTTP/1.1
によるとConnection: Keep Aliveは永続的接続
Connection: closeは非永続性接続ということで理解しました。

自分が取得したいページはKeep Aliveでリクエストしたのですが
closeでレスポンスが帰ってきました。
HTTPサーバーの設定によってKeep Aliveが無視されるようです
なのでKeep Aliveを許していないサーバー相手は
>125のやり方で問題ないですよね?

せっかくなのでKeep Aliveが有効なサーバーでやってみたのですが
send() -> recv() -> send() -> recv() とやると
1回目のrecv()で通信が終わってしまいました(戻り値ZERO)
なのでsend() -> send() -> recv() とやるとうまくできたのですが
これが正解になりますか?

130 :デフォルトの名無しさん:2006/06/18(日) 11:34:54
>>129
Keep-AliveはHTTP/1.0拡張の不完全永続接続
HTTP/1.1はデフォルトでそれを改善した永続接続(persistent connection)
別物なので注意

131 :デフォルトの名無しさん:2006/06/18(日) 11:41:26
>>123
この自己解決に不満があったので質問しました。
ひとつイベントを受け取るたびにResetEventをする必要はないと思ったので。

132 :デフォルトの名無しさん:2006/06/18(日) 12:51:17
いまだにchunkデータってのが理解できないってだけで
HTTP/1.0を投げる奴が多いことに驚いた。

133 :デフォルトの名無しさん:2006/06/19(月) 18:19:56
>132
理解はしてても、いちいちあれ処理するの面倒じゃね?

134 :デフォルトの名無しさん:2006/06/19(月) 20:46:25
1.1でcloseしろよ。

135 :デフォルトの名無しさん:2006/06/19(月) 20:53:10
>1.1でcloseしろよ。

136 :デフォルトの名無しさん:2006/06/19(月) 22:03:34
理解できないならスルーしていいんじゃなかったっけ

137 :デフォルトの名無しさん:2006/06/19(月) 23:27:19
>>134
>1.1でcloseしろよ。
kwsk

138 :コードぐらい晒せ。:2006/06/19(月) 23:37:11
>>131
エスパー希望の方は、とっととお帰りください。

139 :デフォルトの名無しさん:2006/06/20(火) 00:40:17
>>133
クライアントの環境がオーバクォリティ過ぎるから、何度もconnectしたくないな。
keep-aliveで何度も利用しないと次はいつconnectできるかわからん事もあるし。

140 :デフォルトの名無しさん:2006/06/20(火) 12:35:16
httpサーバやプロクシサーバー等の、
帯域制御の昨日はどのようなアルゴリズムが使われているのでしょうか。

141 :デフォルトの名無しさん:2006/06/21(水) 10:41:37
>>140
mod_bandwidthのソースでも読んでみれば?

142 :140 :2006/06/21(水) 13:23:59
レスありがとう。読んでみます。

143 :デフォルトの名無しさん:2006/06/21(水) 21:42:11
httpクライアントソフトをプログラミングしているのですが、、
DataOutputStreamを使ってwriteBytes()メソッドで、
「GET ファイル名 HTTP/1.0」という一行目の要求を送っているのですが、
Etherealでパケットダンプしてみるとなぜか最初の「G」が一つのパケットで、
その後のデータが二つ目のパケットとして送信されています。
そのためプロトコルはHTTPと認識されているのですが、
データのフィールドに関する情報の詳細がEtherealでは見れないようになってしまっています。
結果的にレスポンスが戻ってきてはいるのですが、
これは特にJavaのプログラムのコードに依存することではなく、
特に気にする必要は無いのでしょうか。

144 :デフォルトの名無しさん:2006/06/21(水) 23:35:25
ヒント:フラグメント

漏れはわざとHTTP/0.9とか投げて反応見たりする(w

145 :デフォルトの名無しさん:2006/06/21(水) 23:45:40
>>143
ない。

バイトストリームだから。

146 :デフォルトの名無しさん:2006/06/21(水) 23:47:48
>>144
ちょっとピント外れだね。

147 :デフォルトの名無しさん:2006/06/22(木) 01:50:04
とはいえ、現実には、1byteずつsendしなきゃ>>143のようにはならないべ?
nagleが効いてるから、ネットワーク的には大して問題にはならないだろうけど
さすがにちょっと効率悪くね?>DataOutputStream

148 :デフォルトの名無しさん:2006/06/22(木) 03:04:27
writeBytesだと1文字ずつ出力してるし。
文字列入れてflushしないと効率悪いよ。

149 :デフォルトの名無しさん:2006/06/22(木) 11:42:57
漏れはNW側のスループットを気にするときにはByteArrayOutputStreamに
一旦電文を組み立ててからまとめて write してる。


150 :デフォルトの名無しさん:2006/06/22(木) 20:15:57
なんでDataOutputStream使うんだ?
PrintWriter使えばいい気がするが

151 :デフォルトの名無しさん:2006/06/22(木) 22:47:04
バイトストリームの方がイケメン風じゃね?
文字列だけってナウくない感じ。

152 :デフォルトの名無しさん:2006/06/22(木) 22:55:05
>>150
Don't println to a Socket
http://developer.apple.com/jp/technotes/tn1157.html

153 :デフォルトの名無しさん:2006/06/22(木) 23:18:05
自分でプログラミングしたプロクシサーバーを使ってIEでホームページみたら、
ページの上の方にゴミみたいなデータが大量に表示されるんだけど、
どのような理由が考えられるのかな、、

154 :コードぐらい晒せ。:2006/06/23(金) 00:23:03
そのプロクシサーバーがゴミをぶちまけてんだろ。

155 :デフォルトの名無しさん:2006/06/23(金) 01:13:20
>>153
たまには部屋を掃除しなさい。

156 :デフォルトの名無しさん:2006/06/23(金) 15:24:35
プロクシ鯖にゴミフィルターが付いてない悪寒。
抗菌とか抗ウイルスとかいろいろ売ってるから試してみたら。
もちろん汚れてたら洗浄しないと流量落ちるよ。


マカが居るのか。

157 :デフォルトの名無しさん:2006/06/24(土) 22:46:39
MSNメッセのメンバーのIPアドレスを知る方法ってありますか?

ネットなプログラムを書こうとしてるんだけど、お互いが固定ではないIP
の場合、相手のIPを知る必要がありますよね。手動で相手のIPを入力する
のは手間だし、メッセのデータを使えると便利かなぁとか。

158 :デフォルトの名無しさん:2006/06/25(日) 01:36:23
ない、できたとしたら悪用されるだろ。
どっちかがDDNS登録すればいいじゃない。
無料でできるのとかあるしさ。

159 :デフォルトの名無しさん:2006/06/25(日) 01:54:57
>>158
やっぱりそうですか、残念。

暇つぶしに、固定の鯖を立てないでMMORPGみたいなチャットプログラムを作
ろうとしてたんですけど、なかなかむずいっすね。

160 :157:2006/06/25(日) 02:05:41
>>158
あ、書き忘れ。レスありがとう。

161 :デフォルトの名無しさん:2006/06/25(日) 20:13:59
昔はnetstatしたら相手のIP分かったよね?
いつから変わったんだろ

162 :デフォルトの名無しさん:2006/06/25(日) 20:27:42
UDP知ってる?



163 :21:2006/06/26(月) 03:32:10
>>162
UDP/TCPでんでんじゃなくて、
MSNメッセは昔そうだったんだよ
netstatで見えたんだよ相手が。

164 :デフォルトの名無しさん:2006/06/26(月) 08:07:34
IPアドレスは、国際標準で決まってる。
普通は、プロバイダが発行するIPアドレスしか存在しない。
プログラマはそれに合わせるしかないだろ。
LAN内なら、DHCPサーバが発行するIPアドレスしか存在しない。
DHCPサーバ・DHCPクライアントを自作して、特殊なIPアドレスを持たせるのは自由。


165 :デフォルトの名無しさん:2006/06/26(月) 09:25:26
>>164
詳しく説明してもらおうか

166 :デフォルトの名無しさん:2006/06/26(月) 10:56:45
>普通は、プロバイダが発行するIPアドレスしか存在しない。

???


167 :デフォルトの名無しさん:2006/06/26(月) 11:20:05
IPアドレスがまず割り振られて、
それをドメイン名変換するかしないかはプログラムの自由。


168 :デフォルトの名無しさん:2006/06/26(月) 12:51:07
>>163
馬鹿?
だからUDP使うようになったら相手は見えないんだって。-aしても。
UDPに「接続」はないから。

MSN Messenger Service ProtocolやSIPの規格読め。

169 :デフォルトの名無しさん:2006/06/26(月) 12:56:41
>>164
>LAN内なら、DHCPサーバが発行するIPアドレスしか存在しない。
ちょ、ここkwsk

170 :デフォルトの名無しさん:2006/06/26(月) 14:40:16
さて盛り上がってまいりました

171 :デフォルトの名無しさん:2006/06/26(月) 16:04:27
>>163
ところで、でんでんってもしかして云々(うんぬん)のことですか

172 :デフォルトの名無しさん:2006/06/26(月) 17:13:26
メッセで相手のIPがわからないのはUDPとか関係ないだろ
直接通信してりゃUDPでもパケットキャプチャしたらわかるし
TCPでも間にMSNの鯖経由して通信してるならMSN鯖のIPしかわからん

173 :デフォルトの名無しさん:2006/06/26(月) 18:08:49
サーバ経由通信とUDP通信の両方だろ。> 分からない場合

フアイヤーウオールの設定とか色々絡んでくるから、
`MSNメッセは昔そうだったんだよ'ってのもアレなんだけど。


174 :デフォルトの名無しさん:2006/06/26(月) 18:31:46
>>168
UDPでも直接送られてるならキャプチャしたら分かるよ。
172の言うとおり、TCPかUDPかの問題じゃないでしょ。

175 :デフォルトの名無しさん:2006/06/26(月) 18:36:31
>>174

話の流れを良く読め

>>161

>昔はnetstatしたら相手のIP分かったよね?

と言っておる


176 :デフォルトの名無しさん:2006/06/26(月) 20:26:29
>>175
いやだから昔のMSNメッセンジャーはTCPでpeerに直接継いでたからnetstatしたら見えたし。
話の流れ読めてないのはUDPの話しだした>>162だろ。

177 :デフォルトの名無しさん:2006/06/26(月) 20:44:55
>>176
まるで今のMSNメッセンジャーが直接繋がないような言い方だな。
お前まるでプロトコル理解してないだろ。


178 :デフォルトの名無しさん:2006/06/26(月) 21:02:42
直接繋ぐことがあるならUDPの話しだした>>162が余計バカに見えるじゃん
と言ってみる

179 :デフォルトの名無しさん:2006/06/26(月) 21:03:25
お互いがNATだった場合は直接通信しようがないけどな。
どうやってNATの内側同士でIPパケットを送り合えるか詳しく説明してくれ。

180 :デフォルトの名無しさん:2006/06/26(月) 21:17:49
>>179
UDP でいいならSkypeも使ってるUDP Hole Punching とか。
詳しい説明は自分でググれ。

181 :デフォルトの名無しさん:2006/06/26(月) 21:17:59
昔はルータにポートフォワーディングとかさせてたんじゃね?
だからnetstatで相手のIP見えたんだろ?
で今はリレーノード方式になって見れなくなったとかなんじゃねえの?
そうなると余計にUDPの話を持ってきた>>162の真意が読めなくなるが

182 :21:2006/06/26(月) 21:21:21
netstatで相手が見えない=コネクションはらない=UDP
だからUDPじゃーん俺っててんさーい
>>162でしょ?

183 :デフォルトの名無しさん:2006/06/26(月) 21:27:11
>>161を応援してたけど>>182でUZEEEEEEEEEEと思いました

184 :デフォルトの名無しさん:2006/06/26(月) 22:53:18
WindowsCEでWinInetを使用して、HTTP通信を行っているのですが
CLOSE時に、クライアントからサーバ側にFIN(または、FINと同等のもの)を送信することはできますでしょうか?
やはり、Socketによる構築を行い、プロトコルを制御するしかないの
でしょうか?

185 :デフォルトの名無しさん:2006/06/27(火) 01:55:37
shutdownじゃまずいの?

186 :デフォルトの名無しさん:2006/06/27(火) 02:05:04
コネクション管理はwininetがやってるから無理やろねー

187 :デフォルトの名無しさん:2006/06/27(火) 10:01:21
自前でTCPスタックを作り直すほどの能力が有れば出来るんじゃね?
そこまでするほどの理由はあるのか?

188 :デフォルトの名無しさん:2006/06/27(火) 13:15:37
>>177
ん?
実際今はチャットとかファイル転送とかしない限り直接繋がらないでしょ?
昔はフレンドリストに入れるだけでIPわかったんよ。

189 :デフォルトの名無しさん:2006/06/27(火) 22:45:36
英語でプログラミング勉強スレ

http://academy4.2ch.net/test/read.cgi/english/1151414777/l50

190 :157:2006/06/29(木) 00:03:49
へぇ、昔と今で結構違うんですねぇ、知らなかった。

自宅で鯖立てるのは面倒なんで、CGIが使えるレンタルサーバでも使って、
そこでIPを登録・取得とかでいけるかな。でも、ばれたら怒られそうだ。

>>188
チャットやファイル転送では直接つないでるんですか?それならパケット
みればIP分かりますね。
うーん、Etherreal消してしまったので確認できず・・・。

191 :デフォルトの名無しさん:2006/06/29(木) 00:14:18
netstat -noba


192 :157:2006/06/29(木) 00:30:48
あれ、netstatってDOSプロンプトでも使えたんだ。知らんかったw

193 :デフォルトの名無しさん:2006/06/29(木) 00:32:50
dosで使わないでどこで使うの

194 :デフォルトの名無しさん:2006/06/29(木) 00:35:01
cmd

195 :デフォルトの名無しさん:2006/06/29(木) 00:52:42
>>190
直接繋げてみて、ダメだったら鯖経由になる。

196 :デフォルトの名無しさん:2006/06/29(木) 10:33:58
Dosで使わないでどーすんの

197 :157:2006/06/29(木) 13:43:19
いや、Linuxとか。

198 :デフォルトの名無しさん:2006/06/30(金) 01:56:06
一つのPCに一つのネットワークアドレスを当てて、複数のPC間でTCP/IP通信をしたいんです。
PC毎に数百個のノードを管理します。PC毎にIP割り当てを管理する専用のプロセスがいます。
そして、ノードごとに一意なIPアドレスが割り当てられるようにしたいです。

PCはハブ接続を行っています。

ルータ買わないとどうにもならないもんかな、デフォルトゲートウェイの設定とかでなんとかな
らないでしょうか・・・

199 :デフォルトの名無しさん:2006/06/30(金) 02:40:49
せめてOSくらいは書け
情報が足り無すぎ

200 :デフォルトの名無しさん:2006/06/30(金) 03:16:24
OS:WindowsXP Home
ソケット:winsock

仮にできたとしても、NICに複数IP割り当てを行わなきゃいけないんですかね・・・


201 :デフォルトの名無しさん:2006/06/30(金) 03:23:53
>>198
こんなこと書きたくはないし黙ってればいいのかもしれないが、>>198には
到底その仕事は無理だとおもう・・・
単に極端に日本語に不自由なだけで技術はあるならまた別だけれでも。


202 :デフォルトの名無しさん:2006/06/30(金) 03:33:08

思考は正しくてもアウトプットがへんてこだとアホに見られる好例

なにがしたいのか分からん


203 :デフォルトの名無しさん:2006/06/30(金) 05:02:07
>>198
ノードとか管理プロセスとか関係なくて、単に互いにNWアドレスの異なる複数のNWに属する
PCを単一セグメントのLANに接続したとき、どうルーティングすれば相互に通信できるのか、
っていう質問のような気がする。あってますか?


204 :デフォルトの名無しさん:2006/06/30(金) 05:04:04
>>203

>一つのPCに一つのネットワークアドレスを当てて

この時点でその推測は除外されるかと



205 :デフォルトの名無しさん:2006/06/30(金) 05:05:47
著しく日本語が不自由なかたですね

206 :デフォルトの名無しさん:2006/06/30(金) 05:20:49
>>204
PC1 : NW 192.168.1.0/24 IP-ADDR 192.168.1.1
PC2 : NW 192.168.2.0/24 IP-ADDR 192.168.2.1
てな2台を1つのセグメントでつないで(タコHUBで繋いで)、相互に通信するには?
という質問かな、と。

これなら(Windows の場合)、
PC1 で route add 192.168.2.0 mask 255.255.255.0 192.168.1.1
PC2 で route add 192.168.1.0 mask 255.255.255.0 192.168.2.1
と互いにネットワークルートを設定すればいいような気がする。


207 :デフォルトの名無しさん:2006/06/30(金) 05:58:52
それじゃできないよ

やってみてから書けば?


208 :デフォルトの名無しさん:2006/06/30(金) 06:14:24
やだよいちいちメンドクサイ。
だいたいそんな感じでできるでそ。

209 :デフォルトの名無しさん:2006/06/30(金) 07:46:32
ARPを勉強しなさい

210 :デフォルトの名無しさん:2006/06/30(金) 09:09:04
TCP/IPスタック上で実装されている各種プロトコル規約と
TCP/IPスタックを呼び出してネットワーク通信を行う上位
プログラムの違いを理解すべきかと

211 :デフォルトの名無しさん:2006/06/30(金) 17:32:08
arp -s で手で登録すればいいじゃん。


212 :デフォルトの名無しさん:2006/06/30(金) 18:12:58

目的:各ノード(最終的には数千個)に一意なIPアドレスを振って、相互に通信させる。

まずはじめに、ネットワークテストプログラムを作成しました。この時はテストプ
ログラムで、ノードは最大でも64ノードまででした。ノードごとに使えるポートを管
理する事で相互通信をさせていましたが、
特に問題はありませんでした。

そろそろ本格的に数百のノードで実験を始めようかと思っています。最終的には
数千個のノードが稼動する予定です。

これから先を考えた場合、ポートを使ったノードの管理は不可能です。
そこで、IP単位でノードを管理したくなってきました。

現在、PCが複数台ありますのですべて使う事ができれば、負荷を分散させる事
ができます。PCを複数使う事になれば、PC毎にプロセスを作成することになりま
す。そこで、各PCにネットワークアドレスを割り振り、ネットワークアドレス単位で
各プロセスにIPを割り振らせることが一番楽な目的の解決方法だと考えています。
で、>>198のような質問をしました。

現在、PCに割り振られているIPでないとbind()が成功しない事に気づいて愕然とし
ています。WinXPですとIPアドレスを手作業でNICに結び付けれますが、数千IPだと、
無理があります。NICに範囲指定などで大量のIPを割り当てたいのですが、何か
いい方法はありますか?

213 :デフォルトの名無しさん:2006/06/30(金) 18:28:26
質問の意味不明さかげんからして自分が何をしてるのかもわかってない
だろうな。

たぶん目的はなにかあるんだろうけど、ネットワークをまともに理解して
ないので解決方法を考えた段階ですでにねじれているように見える。

とりあえず地道に勉強しろというぐらいしかアドバイスのしようがないね。


214 :デフォルトの名無しさん:2006/06/30(金) 18:46:36
>>212
>目的:各ノード(最終的には数千個)に一意なIPアドレスを振って、相互に通信させる。
最終的には数千のノード(つまり数千端末)での相互通信が目的で、その運用に近い
テスト(ネットワーク負荷テスト?)を行いたいが、それだけの端末を用意できない。

だから擬似的に1台のPCに複数のIPアドレスを割当て、その割当てたIPアドレス分
のプロセスを起動させ、その起動したプロセスを擬似PCに見立てて通信テストを行い
たい、で、大量のIPアドレス割当ての簡単な方法を探している。

仮に212さんの目的とする手法が見つかったとしても、本手法では意味をなさないと
思うのだが。

最終目的は数千ノードの相互通信ですよね。
本システムを構築する為には、相当数の中継装置(ゲートウェイ・プロキシ・ファイア
ウォール等)を必要とします。
システムテストを行う場合は、実運用に近い形でテストしなとシステム稼動時に予期せぬ
トラブル、パフォーマンス不足、ネットワークトラフィック過多などが発生します。

運用テスト段階に入ってからのシステム全体の見直しとなった場合、目も当てられない
状況になります。
出来るだけ実運用に近い形でのネットワークテストをお勧めします。

215 :デフォルトの名無しさん:2006/06/30(金) 18:50:34
なるほど。

Q: PC上で動かすプロセス(数千あります)が、それぞれ固有のIPアドレスで通信できますか?
A: できませんし、そんなことを考えるのも馬鹿げています。RPC等を用いましょう。


216 :デフォルトの名無しさん:2006/06/30(金) 20:28:35
>>214-215

>一つのPCに一つのネットワークアドレスを当てて

この時点でその推測は除外されるかと



217 :デフォルトの名無しさん:2006/06/30(金) 21:50:28
ノードってなんじゃろう

218 :デフォルトの名無しさん:2006/06/30(金) 22:55:33
「なんかWinnyがそろそろ駄目になるみたいだから
新しくファイル共有ソフトを作りたいのよーママン」
と言っているのではないだろうか。

219 :デフォルトの名無しさん:2006/06/30(金) 23:09:28
>まずはじめに、ネットワークテストプログラムを作成しました。この時はテストプ
>ログラムで、ノードは最大でも64ノードまででした。ノードごとに使えるポートを管
>理する事で相互通信をさせていましたが、
>特に問題はありませんでした。
>
>そろそろ本格的に数百のノードで実験を始めようかと思っています。最終的には
>数千個のノードが稼動する予定です。
>
>これから先を考えた場合、ポートを使ったノードの管理は不可能です。
>そこで、IP単位でノードを管理したくなってきました。


あほかこいつ?ポートで充分じゃん


220 :デフォルトの名無しさん:2006/07/01(土) 01:35:39
あれ、駄目になるの?
俺のクソゲーも少しは売り上げ伸びるかしら

221 :デフォルトの名無しさん:2006/07/01(土) 04:43:40
よくわかんねーけどMPIとかじゃだめなん?

222 :デフォルトの名無しさん:2006/07/01(土) 10:22:27
>>212
あなたがお探しの物は、IP Helper API(iphlpapi)で見つかると思います。

>現在、PCに割り振られているIPでないとbind()が成功しない事に気づいて愕然
>WinXPですとIPアドレスを手作業でNICに結び付けれますが
との記述がありますので、プログラミングが可能なお人かと思いますので、
ググって見て下さい。
ターゲットOSもWindows系に限定できるようなので、iphlpapiで検索すれば
iphlpapiを使用したサンプルを直ぐに見つかります。
後は、目的の機能を実現するユーティリティソフトを作成するだけです。

223 :デフォルトの名無しさん:2006/07/01(土) 20:46:43
AddIpAddress()という関数を使えばよかったのですね。
ありがとうございます。とても嬉しいです。
現在はPlatform SDKをインストールして、AddIpAddress()の仕様を調べています。

最初の第二歩目となったサイトを置いておきますね。

IPHLPAPIを使ってWindowsでネットワーク設定いじるプログラムを書く
ttp://www.geekpage.jp/programming/iphlpapi/

おまけとして、64bit環境のコンパイラも入手できた事はとても大きいです。

本当にありがとうございました。

224 :デフォルトの名無しさん:2006/07/02(日) 20:49:46
recv関数はサーバーから送信がないとどうなるのでしょうか?
簡単に試したら受信0バイトで終了します。
データが送られるまで待つような設定ってできないのでしょうか?

225 :デフォルトの名無しさん:2006/07/02(日) 21:20:04
>>224
ブロッキングrecv()ならデータが来るまでずっと待機。
鯖側でaccept()が返してきたソケット閉じてない?

226 :224:2006/07/02(日) 21:23:50
>>225
ああなるほどです。
HTTP/1.0で試してたのでサーバー側で閉じられたんですね。

227 :デフォルトの名無しさん:2006/07/03(月) 04:40:59
具体的に何がやりたいのか示さないからさっぱりだな。
負荷テストなら、実際と違うから本番で障害出まくりだろうし。
ゲーム鯖プログラムでも作ってるのかな?

簡単なのはベータテスト版を配布して、不特定多数に協力してもらえ。もちろん餌は必要。
世の中は完全なネットワーク環境だけじゃないよ。むちゃくちゃな環境からあの手この手でインターネットに繋げてきてる香具師がいくらでも居る。
手っ取り早くその辺の技術をパクりたければ、既に運用して課金開始してる業者で働け。

228 :デフォルトの名無しさん:2006/07/03(月) 21:05:50
やりたかったのは、adhoc通信の際に用いる通信プロトコルの選定です。
いま、adhoc通信の研究をしているんですが、有力な候補がa, b, c方式とあがっています。
どのチームの責任者も自分の案を押すばかりで、一歩も譲ろうとしません。
んで、私はどのチームの人間とも全く関わりを持たないのですが、というか持たないから
こそかもしれませんが、私のチームでa, b, cをシミュレートするプログラムを作れと言われ
ているのです。

で、何かの縛りをつけて、どこかの方式が不利になると、また喧嘩になるので、ただシミュレート
プログラムを作れとだけ言われています。何の条件もありません。

正体がばれるとまずいのでこれくらいしか書けませんが、とりあえずやりたかったのは
簡単に言えばadhoc通信です。

229 :デフォルトの名無しさん:2006/07/03(月) 21:17:49
そういうのは普通ネットワークシミュレータでやる。
というのは、IP層より下の層の性質が結構効いてくるから。

正直OpenSourceのものを改造すれば間に合うと思う。
「ネットワークシュミレータ」でぐぐって。
適当な板やスレッドはあるのかなあ。


230 :デフォルトの名無しさん:2006/07/03(月) 22:03:41
それを言うならシミュレータじゃないの?

231 :デフォルトの名無しさん:2006/07/04(火) 00:49:10



 ま た 趣 味 レ ー タ か !



232 :デフォルトの名無しさん:2006/07/04(火) 09:38:06
Simulationはシュミレーションではなく、シミュレーションです。
Simulateはシュミレートではなく、シミュレートです。
Simulatorはシュミレーターではなく、シミュレーターです。

Simuをシュミと読むのはバカ日本人だけです。
いいですか? ××× シュミ ××× 大間違い! 違います! こんな読みがまかり通るのは許せません!
シュミレーションとはなんですか? 馬鹿ですか? 何が趣味ですか?
口が回らなくて”シミュ”をうまく言えないのはまあ許してやります。
ですが、書くときまでシュミと糞間違いをするのは死刑モノです。

間違いを指摘してもらえる馬鹿は、まだましです。
五十過ぎたおやじが、「血眼」を「ちなまこ」と言っていて、誰も訂正しません。
血ナマコおやじというあだ名です。
しかも、説教でいつも興奮して言っています。
「いいか! ちなまこになって顧客を開拓しろ!」
みんな笑いを抑えるのに必死です。

シミュレーションを趣味レーションとか言っているやつも、鼻で笑われています。
馬鹿っぷりを露呈する前に、自ら正しましょう。

●シミュレーション( [simulation] 模擬実験 (コンピューターなどを使い実際の現象に似たモデルをつくって実験・研究すること。<原義は「見せかけ」>)
●趣味レーション(日本人がシミュレーションのシミュをシュミ(趣味)と誤った発音をしてしまったことから生まれたでたらめ語)

中には「「趣味レーション」でも意味が伝わればいい」などと居直る害虫野郎がいます。
意味が伝わればいいなら
戸棚を「となだ」と言っていいのですか? 雰囲気を「ふいんき」と言っていいのですか? ボトルを「ボルト」と言っていいのですか?
どうでもいいのですか? 気になるでしょう? 変でしょう?
趣味レーションなんて白痴言葉はすぐにやめなさい! 恥ずかしいから。
Simulationはシミュレーションです!


233 :デフォルトの名無しさん:2006/07/04(火) 11:54:59
>230-232
念のため聞くけど、229の一行目を見た上で釣られてるんだよな?

234 :デフォルトの名無しさん:2006/07/04(火) 17:30:12
ネットワークシュミレータ の検索結果のうち 日本語のページ 約 63 件中 1 - 10 件目 (0.79 秒)
ネットワークシミュレータ の検索結果のうち 日本語のページ 約 12,900 件中 1 - 10 件目 (0.12 秒)

上に探すものがあるのか・・・?


235 :デフォルトの名無しさん:2006/07/04(火) 20:57:24
>>232はコピペかなんかだろうか

バカすぎて萎えるな

236 :デフォルトの名無しさん:2006/07/09(日) 11:42:37
ネットワークにあるバイナリファイルを取得したいのですが、
途中までできて、最後まで取得できません。

以下にソースを示します。
どこが悪いのでしょうか?

int i = 0;

while(1){
 err = recv(s, recvbuf, RECVSIZE, 0);
 if(err == 0){
  interr_code = WSAGetLastError();
  printf( "Error: 受信失敗\n" );
  break;
 }
 if( err == SOCKET_ERROR){
  printf( "Error: 受信失敗\n" );
  break;
 }
 fwrite( recvbuf, sizeof(char), strlen(recvbuf), file );

 memset( recvbuf, 0, sizeof(recvbuf) );
 i++;
}


237 :236:2006/07/09(日) 11:46:40
int i; はデバック用のカウンタです。
エラーが発生した時( err==0 )に
i の値をデバッカで見てみるのですが
100〜300 とエラーが発生するタイミングもランダムです。

WSAGetLastError() は ゼロを返します。

238 :236:2006/07/09(日) 11:47:44
sprintf( szBuffer, "GET /galerie/img/th2_573.jpg HTTP/1.0" );
send(s, szBuffer, strlen(szBuffer), 0);

sprintf( szBuffer, "Accept: */*" );
send(s, szBuffer, strlen(szBuffer), 0);

sprintf( szBuffer, "Accept-Encoding: gzip" );
send(s, szBuffer, strlen(szBuffer), 0);

sprintf( szBuffer, "Connection: close" );
send(s, szBuffer, strlen(szBuffer), 0);

sprintf( szBuffer, "Host: www.crystalxp.net" );
send(s, szBuffer, strlen(szBuffer), 0);

sprintf( szBuffer, "Referer: http://www.crystalxp.net/galerie/img/index.html" );
send(s, szBuffer, strlen(szBuffer), 0);

while() 前に 送っているリクエストを載せておきます。

239 :デフォルトの名無しさん:2006/07/09(日) 11:53:31
  interr_code = WSAGetLastError();
if (interr_code == 0) {
continue;
}

240 :デフォルトの名無しさん:2006/07/09(日) 12:12:38
recvsize = RECTSIZE;
while(recvsize > 0){
 err = recv(s, recvbuf, recvsize, 0);
 if( err == SOCKET_ERROR){
  printf( "Error: 受信失敗\n" );
  break;
 }
 recvsize -= err;

 fwrite( recvbuf, sizeof(char), err, file );
}
こんな乗りで

241 :デフォルトの名無しさん:2006/07/09(日) 12:18:01
>>236
recvの戻り値は、
整数:読み取ったデータのレングス
0:TCP/IP通信の相手側がソケットのクローズをした可能性が有り、
 WSAGetLastErrorで詳細を確認
SOCKET_ERROR:ソケットI/Oエラーが発生、WSAGetLastErrorで詳細を確認

バイナリデータの受信を行っているのに、受信データの有効長を
strlenで確認していることがそもそもの間違い。
バイナリデータなのだから、0x00もバイナリデータと認識すべき。

242 :デフォルトの名無しさん:2006/07/09(日) 12:19:24
これはひどい、ソースコードだ。

sendlen = strlen(ss);
total = 0;
err = 0;
while(total < sendlen){
err = send(s, szBuffer, sendlen, 0);
if(err == SOCKET_ERROR)
break;
total += err;
}


243 :236:2006/07/09(日) 15:39:52
>>239,240,241

recvsize -= err;
ですか、いいですね

>バイナリデータなのだから、0x00もバイナリデータと認識すべき。
そのとおりですね。ちょっと暑かったので手を抜・・・げふげふ

while( recvsize > 0 ) は参考になりました
ありがとうございました。

244 :デフォルトの名無しさん:2006/07/10(月) 00:36:49
>>240
相手がいきなりクローズしたら無限ループになるぞ。

>>241
> 0:TCP/IP通信の相手側がソケットのクローズをした可能性が有り、
>  WSAGetLastErrorで詳細を確認

recv が 0 を返した時に WSAGetLastError() なんか呼んじゃ駄目だよ。

245 :工房:2006/07/10(月) 05:01:55
Javaでネットワークプログラミングの勉強をしたいのですがおすすめの本はありますか?
ネットワークの知識は基本技術者レベルです。
この本を検討したんですが、内容が古いそうなのでやめました。
http://www.amazon.co.jp/gp/product/4873110610/249-2208343-5734750?v=glance&n=465392
夏休みにこの分野をおさえたいと思っています。
よろしくお願いします。

246 :デフォルトの名無しさん:2006/07/10(月) 09:39:26
まずCで組んで基本を押さえたほうがいいよ。ほとんどの実装例(ソース)はCが多い。
応用でJavaに逝ってくれ。

暇ならホームページでも作ってログでも残してくれ。

247 :デフォルトの名無しさん:2006/07/10(月) 10:02:12
Comer本のJava版があればいいのにな。

248 :デフォルトの名無しさん:2006/07/10(月) 10:09:12
そもそもJavaは扱うレイヤが違うから
Comer本見たいな内容は書けないのでは

249 :デフォルトの名無しさん:2006/07/10(月) 11:20:59
書けるよ。
packet caputureも出来るしね。>>5

そういうのは調べてから書き込みましょう。

250 :工房:2006/07/10(月) 20:20:41
>>246
なるほどCですか。Cも本当に基本しか知らないので、ずっとやってきたJavaでやろうと
思っていました。
Cやるんならこの際coLinuxでもいれてみようかなぁ

251 :デフォルトの名無しさん:2006/07/11(火) 00:14:57
>>249 本読んだことないの?
>>250 PCもう1個中古で買ってLinux入れたほうがいいよ

252 :工房:2006/07/11(火) 01:35:58
>>251
家そんな裕福でないので、とりあえずもう一台は無理っぽいです。パソコンも
家族共用ですし…
学校のパソコンも全部Windows;;
htmlとphpとMySQLが一応使えるので、サイト構築でお金稼ごうかなと思ってたり。
アドバイスの通りCでやってみようかな、webでもCで解説しているのが多いですしね。

253 :デフォルトの名無しさん:2006/07/11(火) 16:08:06
じゃあ稼いでからPC買えばいいじゃん。

254 :デフォルトの名無しさん:2006/07/11(火) 16:15:22
>>252
マジレスするとリアル工房にそんな仕事頼む所などないぞ。
コネがありゃ別だが。
素直にバイトして金稼げ。

255 :デフォルトの名無しさん:2006/07/11(火) 19:43:59
htmlとphpとMySQLが一応使えると稼げると聞いて飛んできました!!

256 :デフォルトの名無しさん:2006/07/11(火) 19:52:58
>>252
3万持って秋葉原行ってみ。立派なディスプレイ付中古が買えるから。
ディスプレイいらんなら、3万で新品PCが買える。

257 :デフォルトの名無しさん:2006/07/12(水) 00:05:52
qemu で。

258 :デフォルトの名無しさん:2006/07/12(水) 01:35:15
>>245
個人的にはオーム社のTCP/IPソケットプログラミング 2冊がおすすめ
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06520-0
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06519-7


259 :デフォルトの名無しさん:2006/07/12(水) 01:39:12
自分はこれが好きだ
http://www.amazon.co.jp/gp/product/4822221199

260 :デフォルトの名無しさん:2006/07/12(水) 06:36:12
>>259

一応カートには入れてみたものの

●表紙が気に入らない

●「いまどきの〜」というタイトルに不信感がある

とりあえず保留かな


261 :デフォルトの名無しさん:2006/07/12(水) 14:48:40
>>259
tool紹介とRAW socketだけいじる内容か。
しょぼいな。

262 :デフォルトの名無しさん:2006/07/12(水) 15:54:43
普通のクライアント、サーバアプリ
を作るための本がほしいぞ
できればセキュアなやつ

263 :デフォルトの名無しさん:2006/07/13(木) 00:27:55
こんにちは。C++とネットワークの勉強最近始めました。
ネットワークプログラミングの基礎知識
http://x68000.q-e-d.net/~68user/net/c-http-1.html(ソース)
のページを見ながら勉強してます。

C++ builder6で、httpクライアントhttp-client.cを
コンパイルしたら下記のようなエラーがでました。
linuxのプログラミングだからだと思うんですが、
これを動かすためには、エラーや警告が出た関数、構造体、
インクルードファイルをみて、windows用に変えればよいと
予想してますが、

・インクルードファイルを変えて、関数名をちょっと変えるぐらいで
 動いたりするんでしょうか?

・きちんとプログラムを理解して大幅に変更しないとだめでしょうか?
winsock2を使うんでしょうか。

<続きます>


264 :デフォルトの名無しさん:2006/07/13(木) 00:28:37
<エラー内容>
エラー E2209 http-client.c 7: インクルードファイル 'sys/socket.h' をオープンでき
ない
エラー E2209 http-client.c 8: インクルードファイル 'netdb.h' をオープンできない
エラー E2209 http-client.c 9: インクルードファイル 'netinet/in.h' をオープンでき
ない
エラー E2209 http-client.c 10: インクルードファイル 'sys/param.h' をオープンでき
ない
エラー E2209 http-client.c 11: インクルードファイル 'sys/uio.h' をオープンできな

エラー E2209 http-client.c 12: インクルードファイル 'unistd.h' をオープンできな

エラー E2450 http-client.c 19: 未定義の構造体 'sockaddr_in'(関数 main )
エラー E2449 http-client.c 19: 'server' のサイズが不明、あるいはゼロ(関数 main )
エラー E2450 http-client.c 19: 未定義の構造体 'sockaddr_in'(関数 main )
エラー E2450 http-client.c 19: 未定義の構造体 'sockaddr_in'(関数 main )
エラー E2449 http-client.c 19: 'server' のサイズが不明、あるいはゼロ(関数 main )

警告 W8065 http-client.c 68: プロトタイプ宣言のない関数 'gethostbyname' の呼び出
し(関数 main )
警告 W8069 http-client.c 68: 移植性のないポインタ変換(関数 main )
エラー E2450 http-client.c 74: 未定義の構造体 'sockaddr_in'(関数 main )
エラー E2109 http-client.c 74: 許されない型(関数 main )
・・・・(倍あるので省略します)

よろしくお願いします。

265 :デフォルトの名無しさん:2006/07/13(木) 00:42:44
> エラー E2209 http-client.c 7: インクルードファイル 'sys/socket.h' をオープンでき

このエラーにすら対処できないようでは、このスレに来る以前のレベルだと思う。

初心者スレにでも行った方がいいと思うよ。

266 :デフォルトの名無しさん:2006/07/13(木) 00:43:15
Winsockを使うならPGの一部を訂正するだけで問題はない、けれども
それよりも、まずWinsockの本を買ってくるほうが先だと思う
ちゃんと理解してないのにPGを組もうとするのは間違ってると思わない?

267 :デフォルトの名無しさん:2006/07/13(木) 00:46:01
Cygwinインストールすれば、ほとんどの問題は解決するんじゃないか。
実際に上のソースがコンパイルできるかどうかは知らんけど。

268 :デフォルトの名無しさん:2006/07/13(木) 00:57:32
でも、CygWinは一部のAPI(inet_lnaofとか)がサポートされてないからねえ。
どの程度までネットワークを触りたいのか知らないけど、
先に環境などの基礎固めしておいたほうが良いと思う。

269 :デフォルトの名無しさん:2006/07/13(木) 01:22:56
cygwinのインストールができません。
cygwinをgui環境で使うにはどうしたらいいんですか?

270 :デフォルトの名無しさん:2006/07/13(木) 01:26:02
>>265
了解しました。
初心者スレに戻っていろいろ勉強してきます。
ネットワークのことなのでこちらの方が良いのか
と思って伺いました。

>>266
初心者スレで、「Winsock2.0プログラミング」進められたので、
早速本屋に行ってみました。ちょっと高かったので長時間立ち読みしました。
今回の問題が解決できないってことは、全然だめってことなんですね。
もう一回勉強してから本購入してみようと思います。

>>267
Cygwinですか。ありがとうございます。
早速調べます。

>>268
環境などの基礎固めですか。
了解しました。

271 :デフォルトの名無しさん:2006/07/13(木) 01:36:00
windows用なのになんで68kのを・・・

272 :デフォルトの名無しさん:2006/07/13(木) 02:18:36
すいません、ちょっと質問させてください。

非同期で動くプロキシ処理を試しているんですが、
1.FD_ACCEPTが来たらWSAAsyncSelect()で準備。
2.クライアントのコネクションを受付け、FD_READが来たら受信する。
3.Async→ 接続要求先へconnect→ Async→ 受信データをそのままsend→
  (\nだけの空行を追加送信?)→ 応答を待つ。
という流れを考えています。

大まかには↑のような流れで間違ってはいないでしょうか?

273 :270:2006/07/13(木) 03:58:53
>>271
コードにコメントが付いていて
しかも詳しい解説があるので、毎日のように
見に行ってしまいます。

初心者としては、あちこち調べまわらなくても
良いので毎日のように見に行ってしまいます。
WINSOCKとどのあたりが違うのか、いまいちわかりませんが
とりあえずネットワークプログラミングの感覚だけでも
掴みたいなぁと。

動かした結果も載っているんですが、自分でも
動かしたいと思いました。

274 :デフォルトの名無しさん:2006/07/13(木) 05:57:58
>>273

Winsockでの同じようなサイトが無いっていう意味だよね?

じゃあさ、君がWinsockでうまく動くように出来たら公開してよ。


275 :デフォルトの名無しさん:2006/07/13(木) 19:47:43
>>274
まだわからないことがたくさんで、
調べまくって、とにかく暗記している状態です。
winInetライブラリのhttp,ftpなど勉強しました。

linuxのシステムコールを使うためのライブラリが
あることがわかりました。

これからwinSockがんばります。

勉強始めたばかりで、
C++の知識、C++ builuderの使い方、API、linuxの知識が
ほとんど無かったので苦労してることがわかってきました。;;

感覚とか、何を勉強すれば良いのか、わかってきたので
今日また本屋に行ってみたんですが、昨日全然歯が立たなかった
本が急にポンポンわかるようになりました。

>じゃあさ、君がWinsockでうまく動くように出来たら公開してよ。
人様に説明できるぐらいの腕前になれるようがんばります。

276 :デフォルトの名無しさん:2006/07/13(木) 22:24:40
最近勉強し始めた初心者です。どなたか教えて下さい。
winsockでサーバーとクライアントの単純な物を作ったりして
練習してました。
もっと理解を深めようと、色々なサイトのサンプルを眺めていて
一つ疑問に思ったことがあります。

普通サーバーの方だと
ソケット作ってバインドしてからlisten()で待ち受ける準備して
acceptで接続を待つって感じだと思うんですが

windowsプログラムの場合だとlistenをセットしたら後は
メッセージプロシージャで待つだけみたいな感じで
メッセージ確認して初めてacceptするようなんですが
これはwindowsが勝手に、ループで接続確認をやってるのと同じことを
してくれてるということなんでしょうか?



277 :デフォルトの名無しさん:2006/07/13(木) 23:01:35
イベントドリブン

278 :デフォルトの名無しさん:2006/07/13(木) 23:51:15
>>276

マルチスレッドにすればそういうの気にしなくてもよくなる

279 :デフォルトの名無しさん:2006/07/14(金) 02:21:31
socketで認証つきプロキシを通過するにはどうすればいいんでしょうか?

280 :デフォルトの名無しさん:2006/07/14(金) 02:54:59
>>278
ということはスレッド作って、そっちで接続待機してって感じで自前で?作って
windowsのメッセージ処理ではやらないってすればwindowsに頼らないで
出来るってことなのかな
windowsプログラムで作る場合は、メッセージでやる方が楽だけど
実際はどっちがいいでしょうか?


281 :デフォルトの名無しさん:2006/07/14(金) 07:15:34
普通のやりかたしとけ

282 :デフォルトの名無しさん:2006/07/14(金) 13:21:19
まともに相談に答える気が無いなら黙っててくれよ

283 :デフォルトの名無しさん:2006/07/14(金) 13:59:40
>>280
ソケットAPIにおいての "accept" とは、正確にはソケットキューにキューイング
された接続要求を取り出すのであって、 "accept" でクライアントからの接続を
待つわけではない。

Windowsメッセージに頼ることなく、且つ、非同期処理的な仕組みを実現する場合
は、"select" と組み合わせることで可能とです。
"accept" から戻された新たな接続処理は、その接続処理を実行する関数をスレッド
として起動すれば、Windowsメッセージに頼らなくても出来ますよ。

>windowsプログラムで作る場合は、メッセージでやる方が楽だけど
>実際はどっちがいいでしょうか?

通信サーバーに特化するのであれば、Windowsメッセージに頼らない方がプログラム
の構成がシンプルになると思う。

284 :デフォルトの名無しさん:2006/07/14(金) 14:01:37
>>282
お前の指図を受けるいわれは無い

285 :デフォルトの名無しさん:2006/07/14(金) 14:47:48
HTTPでレジュームを実装したCかC++のソースってありますか?

google で "レジューム .c socket" で検索したのですが
見つかりませんでした


286 :デフォルトの名無しさん:2006/07/14(金) 15:01:57
>>276 == >>282

>普通サーバーの方だと
>ソケット作ってバインドしてからlisten()で待ち受ける準備して
>acceptで接続を待つって感じだと思うんですが

それが普通で Windows が普通じゃないと思ってるから悩んでるんだろ?

じゃあ普通のやりかたしとけって言ったんだけど何か不満?




287 :デフォルトの名無しさん:2006/07/14(金) 15:08:57
レジュームといわれるやつはHTTP1.1のRangeヘッダを使ってファイルの一部分を
getしてるだけ。

ライブラリになってるものが欲しければlibghttpとか、完結してる奴が見たければ
wgetとかでいいんでないの?


288 :デフォルトの名無しさん:2006/07/14(金) 15:25:19
ども見てみます

289 :デフォルトの名無しさん:2006/07/14(金) 17:08:07
とりあえずRFC2616にも目通しとけよ

290 :デフォルトの名無しさん:2006/07/14(金) 20:19:33
>>283
windowsに頼らないでやったら、もしかしたらあまりよくないのか
よくわからなかったのですが、そんなことはないんですね
色々わかりました。ありがとう


>>286
気付いてるかもしれないけど別人です

291 :デフォルトの名無しさん:2006/07/15(土) 22:10:53
初歩的で申し訳ありませんが、質問よろしいでしょうか?
環境は XP、.NET 2005 で、Winsock2 を使ったネットワークプログラミングにチャレンジしています。

練習として、WSAAsyncSelect を用いた非同期の1対多のチャットソフトを作っています。
サーバにおいて、WSAAsyncSelect で指定したウィンドウに FD_READ が届いた時、
メッセージがどのクライアントから届いたのかを知るにはどうすれば良いのでしょうか?

クライアントごとにソケットを作成しているので、誰からのメッセージかが分からないと、
recv 関数の第一引数にどのソケットを指定していいかが分からずに困っています。
よろしくお願いします。




292 :デフォルトの名無しさん:2006/07/15(土) 22:37:12
WSAAsyncSelect FD_READ wParam で調べると良い

293 :291:2006/07/15(土) 22:45:58
>>292
ありがとうございます。解決です。
FD_READ ばかりに気を取られて、そもそも lParam に関係なく wParam の値が云々という発想にいたっていませんでした。


294 :デフォルトの名無しさん:2006/07/15(土) 23:16:14
クライアントで、なんかコマンドを送信して、サーバーからの応答を受信する、
ってプログラムで、まだ何にも送信してないのにFD_READが発生して
データがきたら、どうするのが普通?

受信してエラーにする?
無視する?でも、
無視した場合、送信後にrecvしたら、結局、受信することになるのか?

295 :デフォルトの名無しさん:2006/07/15(土) 23:47:10
サーバからの応答の結果生じる処理の重大性による。

としか返答できんわな

296 :デフォルトの名無しさん:2006/07/16(日) 00:09:30
プロトコルの勉強をし直した方がよさげ

297 :デフォルトの名無しさん:2006/07/16(日) 00:16:04
VC++2005のTcpClientで、ある装置から送られてくる画像データをリアルタイムで
表示するアプリを製作中ですが、デバッグしたところ不可解な現象がでました。
当初から使用していたノートPCでは動作良好だったのですが、別のディスクトップPC
で動作させてみたところ、画像が約10秒も遅れて表示されてしまいます。
ディスクトップPCはCPUもLANカードもノートPCには劣ってません。
TcpClientのプロパティを見るとNoDelayというものがありましたが、関係しますでしょうか。
NoDelayは設定してませんでしたのでFALSEになってました。
装置は今のところ使えないのでプロパティを変更して確認することはしておりません。



298 :デフォルトの名無しさん:2006/07/16(日) 00:36:14
ディスクトップPCとあるから釣りだと思いたいが

299 :デフォルトの名無しさん:2006/07/16(日) 02:07:09
Nagelか?それにしては10秒って数字が大きすぎると思うが。

300 :デフォルトの名無しさん:2006/07/16(日) 06:50:24
300

301 :297:2006/07/16(日) 08:19:57
全然釣りではありません。
画像データといいましたが、音響レーダーのデータです。
今ソースを見直したところ、TcpClientのReceiveBufferSizeを6000000(6M)も設定しているので
すが、ReceiveBufferSizeがフルになるまで、受信を待たされるようなことは起こるのでしょうか。
ただノートPCでは、全く同じソフトを動かして遅れないんですよ。
デスクトップ(タワー)のみギガビットイーサが搭載されているので、これが影響してるんですかね。


302 :デフォルトの名無しさん:2006/07/16(日) 08:31:56
>>297
ethereal辺りで通信状況を調べて原因を割り出せ('A`)

303 :デフォルトの名無しさん:2006/07/16(日) 08:33:20
>デスクトップ(タワー)のみギガビットイーサが搭載されているので

そういう大事なことは先に言った方がいいよ

304 :デフォルトの名無しさん:2006/07/16(日) 11:47:04
もう、UDPでいっちゃえよ。

305 :デフォルトの名無しさん:2006/07/16(日) 20:00:49
俺は大人なのでディスクトップには突っ込まない

306 :デフォルトの名無しさん:2006/07/16(日) 21:33:30
disktop
desktop
discotop

307 :デフォルトの名無しさん:2006/07/20(木) 00:22:26
hoshu

308 :デフォルトの名無しさん:2006/07/22(土) 01:55:36
正直、正しいソケット通信の終り方が、いまだに良く分からん・・・
・・・そんな俺が書いたプログラムが、世の中にイッパイでまわってるのさ

おまえらもコネクションの切り方とか適当だろ?

309 :デフォルトの名無しさん:2006/07/22(土) 03:00:59
ほっとけばいつか切れるし

310 :デフォルトの名無しさん:2006/07/22(土) 03:12:50
>>308
”正規解放 ソケット”でぐぐると幸せになれるかも。

311 :デフォルトの名無しさん:2006/07/22(土) 05:05:07
ググる前にsocket FAQ読め

312 :デフォルトの名無しさん:2006/07/22(土) 07:24:32
つか本買え

313 :デフォルトの名無しさん:2006/07/22(土) 09:00:34
Windowsで

<sys/socket.h>

を使えるライブラリってありますか?
gcc ではなく bccで利用したいのですが

やはり winsocket.h で書くしかないのでしょうか?


314 :デフォルトの名無しさん:2006/07/22(土) 09:32:31
Cygwin以外ありえない。
socket<--->Winsockなラッパーでも書いて表面上は同じように振舞わすくらいしかないんじゃね?

315 :128:2006/07/22(土) 12:07:37
w

316 :デフォルトの名無しさん:2006/07/22(土) 15:05:23
ソケットに対応させたC++streamを作ろうとして挫折した俺ガイル

317 :Mac:2006/07/22(土) 23:05:12
マックのノートを購入するんだけれど、
マックでプログラミングするのって、
Windowsでプログラミングするのとちがうの?
今WindowsのCプログラミングを勉強してるんだけど、
マックでもCプログラミングを同じようにできるのかな?
誰か教えて!!

318 :デフォルトの名無しさん:2006/07/22(土) 23:11:15
ネットワークを絡めて喋れ。


319 :デフォルトの名無しさん:2006/07/22(土) 23:29:36
ネマックのノートを購入するんだけれど、 マ
ックでプログラミングするのって、 Windowsでプログラミングするの
とちがうの?
ワ今WindowsのCプログラミングを勉強してるんだけど、 マッ

クでもCプログラミングを同じようにできるのかな? 誰か教えて!!


320 :デフォルトの名無しさん:2006/07/23(日) 01:11:42
すごいな

今、AppleTalkを勉強して極めるなんて、
マニアックjだな

321 :デフォルトの名無しさん:2006/07/23(日) 02:06:32
>>320
つれるか?

322 :デフォルトの名無しさん:2006/07/23(日) 02:33:47
>>317
Mac の方が Socket も C もオリジナルに近い

323 :デフォルトの名無しさん:2006/07/23(日) 05:30:40
質問です。
WIN2k、VC++6.0、Winsock2で組んでいますが、
稼動中のSOCKETの総数を調べる方法がわかりません。
いくつSOCKETが動いているか調べる方法はありますか?
お願いします。

324 :デフォルトの名無しさん:2006/07/23(日) 06:01:15
netstat -a

325 :デフォルトの名無しさん:2006/07/23(日) 06:24:13
>>324
プログラムの中で調べて、値をプログラムに反映させたいのです。

326 :デフォルトの名無しさん:2006/07/23(日) 06:34:48
netstat.c

327 :デフォルトの名無しさん:2006/07/23(日) 08:49:13
>>323
IP Helper API(iphlpapi)で目的の情報は取得できます。

IPHLPAPIを使ってWindowsでネットワーク設定いじるプログラムを書く
ttp://www.geekpage.jp/programming/iphlpapi/

328 :323:2006/07/23(日) 19:39:24
>327
IPHLPAPIってなんか難しそうですね。

ソケットを3つ作って(A,B,C)
sock_B=accept(sock_A);として
Sock_AにBが接続されたらSock_Cが別の場所に接続しに行って、
Sock_Bが切断されたらSock_Cも切断する。
Sock_Aはそのまま。

こんなのを作りたかったんですが、結構面倒なんですね。

329 :デフォルトの名無しさん:2006/07/23(日) 19:49:59
socketの稼動数と>>328のしたい事の関係がぜんぜん分からない。
マルチスレッドにすればいいだけ茶宇野?

330 :デフォルトの名無しさん:2006/07/23(日) 19:57:18
>>328
それのどこが面倒なのかよくわからない。


331 :デフォルトの名無しさん:2006/07/23(日) 20:10:42
>>328
> sock_B=accept(sock_A);として
> Sock_AにBが接続されたら

この時点で意味がわからん…

332 :デフォルトの名無しさん:2006/07/23(日) 21:28:10
アホには使えないライブラリなんですよ

333 :323:2006/07/23(日) 22:03:55
sock_Bが生きてるかどうかの確かめ方がわからんから、
ソケットの総数が1個減ったらsock_Cを切断すればいいと思ったんですよ

334 :デフォルトの名無しさん:2006/07/23(日) 23:14:27
ぱっと見、その考え方はおかしいと思う。

> sock_Bが生きてるかどうかの確かめ方がわからんから、

sock_B ってお前のプログラムが操作するんじゃないの?

> ソケットの総数が1個減ったらsock_Cを切断すればいいと思ったんですよ

ほかのプロセスがその間ソケット生成/消滅しない保証はあるのか?

335 :323:2006/07/24(月) 02:56:02
他の方法を考えてみます
ありがとうございました

336 :デフォルトの名無しさん:2006/07/26(水) 02:46:52
http proxyで、あるURLに対してアクセスして、
あるレスポンスコードが返ってきたら、ブラウザに対して
別のページを表示する、ということがしたいのですが、
こういうことができる拡張可能なproxyってありませんか?
今のところjettyしか見つかってないんですが、他にありましたら
ご教示ください。
よろしくお願いします。

337 :デフォルトの名無しさん:2006/07/26(水) 03:20:12
>>336
板違い。ソフト板とかにgo

338 :デフォルトの名無しさん:2006/07/26(水) 03:22:21
横取り丸は?
スレ的にはレスポンスコード見てlocationを足すproxyを作れば
いいわけだ

339 :デフォルトの名無しさん:2006/07/28(金) 15:52:49
C++言語でwinsock(TCP)勉強中です。
ネットワーク入門書のチャットのクライアント、サーバ
何度も打ち込んで覚えて、大体わかってきました。
これから、チャットとファイル交換をできるように
したいのですが、どのようにするのかわかりません。

1.ファイルの中身を読み込んで、
[ファイルの名前]:[ファイルの中身のデータ]
というう風なフォーマットにして送信。
2.データを受け取った側で、ファイルを作って
[ファイルの名]:[ファイルの中身のデータ]
を書き込むとファイルを送ったことになるのでしょうか?

これだと、ファイル名とデータの中身しかわからず、
ファイルの作成日とかその他の情報が送れないので、
ファイルそのものを送ることがしたいです。

アドバイスよろしくお願いします。


なにかお勧めの本やサンプルコードのある
サイトなどもご紹介いただけると助かります。

340 :デフォルトの名無しさん:2006/07/28(金) 15:57:36
[ファイルの名前]:[ファイルの作成日とかその他の情報]:[ファイルの中身のデータ]
というう風なフォーマットにして送信。

341 :デフォルトの名無しさん:2006/07/28(金) 16:11:39
>>340
回答ありがとうございます。
そういう風に送るものなんですね。
さっそくやってみます。

342 :デフォルトの名無しさん:2006/07/28(金) 16:32:42
いや、決めたのはきみだから

343 :デフォルトの名無しさん:2006/07/28(金) 16:48:35
>>342
了解しました。
こういう風に送ることもできるんですね。

通常はどのように送るものなのでしょうか?
田舎なので、書店に行ってもファイルを送信するサンプルが
載ってる本が無いんです。
アマゾンでもどれを買っていいのやら・・・。

344 :デフォルトの名無しさん:2006/07/28(金) 16:52:49
なにを「通常」と思ってるのか知らんが、世の有名なプロトコルがどのようにやってるのか
知りたければRFC読め。

345 :デフォルトの名無しさん:2006/07/28(金) 18:14:10
Content-Name: ファイルの名前
Content-Type: 拡張子
Content-Length: サイズ
Content-Created: タイムスタンプ
Content-Encoded: Base64
(改行)
---- Base64 のデータ ----
---- Base64 のデータ ----
---- Base64 のデータ ----
---- Base64 のデータ ----
---- Base64 のデータ ----

みたいなのが現在の流行

346 :デフォルトの名無しさん:2006/07/28(金) 18:15:35
>>344
ありがとうございます。
httpとかftpなど、さっそくRFC読みました。自分初心者で
頭も悪いのであまりわかりませんでした。
転送のデータ構造がどうなっているのか書いて
あったようなのですが難しいです。

えっと、
・ファイルそのもののデータ構造で送信
・ファイルを開いて中身を送信
する方法があるような気がしているのですが、
この解釈でよかったでしょうか?

ファイルそのもののデータ構造で送信する
ときなんですが、
int send(SOCKET sock, char* buf, int len, int flag)
このsend関数のbufにファイル構造のデータを入れて送信すれば
いいんでしょうか。

手元の本のFTPクライアントは、get関数みたいなのを
使っているんですが、ファイル構造そのものを送信しているのか
[ファイルの名前]:[ファイルの作成日とかその他の情報]:[ファイルの中身のデータ]
のようになんかのファーマットに直してから送信しているのかとか
わからないし。

いろんなことがわかりません。
脳が溶けてきました。
よろしくお願いします。

347 :デフォルトの名無しさん:2006/07/28(金) 18:17:44
>>345
おおお、なんか恥ずかしい返事書いているときに。
ありがとうございます。

348 :デフォルトの名無しさん:2006/07/28(金) 18:29:22
>>346
「ファイルそのもののデータ構造」ってのはファイルシステム(FAT,NTFS,etc)によって異なるし、
ネットワークで伝送するフォーマットも規定されていない(ことが殆ど)ので、
ファイルの中身+いくつかの属性(名前、生成日時等)を適当なプロトコルで送れば十分。

>[略]このsend関数のbufにファイル構造のデータを入れて送信すれば
>いいんでしょうか。
単一ファイルに対してそんなことが可能なファイルシステムやOSは無いと思う。
パーティション丸ごとなら送れると思うが。

349 :デフォルトの名無しさん:2006/07/28(金) 21:48:05
ネットワーク対戦ゲームを作ろうとしているのですが、
Winsock2を使って、
マルチスレッド+イベントオブジェクト
で基幹処理を組んで実験してみたところ、
WSAWaitForMultipleEventsは、
イベントが着ていても、10ms単位でしか処理が帰りませんでした。
(具体的には、イベントが検知されたときの時刻を記録したら、
最速でも10msの時間が空いていた)
ゲームのループは60fps=16ms単位でやろうとしているので、
最大10msの受信遅延は結構大きな壁になりそうで困っています。
(毎フレーム通信することに対しての突っ込みは置いておいて)

なるべく素早く反応を返したい場合、
非同期モードのウィンドウメッセージで組むべきなのですか?
それとも、イベントオブジェクトのチェック
の10msの間隔を縮める方法などがあれば教えてもらえませんか・・・?

350 :デフォルトの名無しさん:2006/07/28(金) 21:54:29
>(具体的には、イベントが検知されたときの時刻を記録したら、
>最速でも10msの時間が空いていた)

なにで時間計測した?
システム時間の計測精度がそもそも10ms


351 :デフォルトの名無しさん:2006/07/28(金) 22:41:30
>>350
あ!!!
めんどくさがって言語の標準の時刻系関数使ってました

TimeGetTime使ったら全然違いました〜
ちゃんと1ms単位(計測精度単位)で動作してましたwwww

鋭い突っ込みありがとうございました
これで不安がなくなったー

352 :デフォルトの名無しさん:2006/07/29(土) 17:24:20
質問です。
環境は、XP sp2、VS.net2003でManagedC++(C++/CLIじゃない)を使用してます。
サーバーを書いてます。

サーバーソケットを非同期モードにし使用してるので、-1が返るまでrecvしているのですが、
クライアントが接続後、最初のデータを正常に受信したあと(全部送り終わり、サーバー側も正常に全部受信したあと)
-1が返り、WSAGetLastErrorの戻り値を見るとWSAEWOULDBLOCKではなく、
5(アクセスが拒否されました)が返ってきます。
それ以降、このエラーを無視し処理を続け手も正常に受信できます。
その後、正常に送受信できるので無視してるのですが、無視してかまわないものなのでしょうか?

353 :デフォルトの名無しさん:2006/07/29(土) 17:47:03
クライアントは送り終わるまで待ってるんでしょうか

354 :デフォルトの名無しさん:2006/07/29(土) 18:01:00
>>352
> クライアントが接続後、最初のデータを正常に受信したあと(全部送り終わり、サーバー側も正常に全部受信したあと)
(ry
> それ以降、このエラーを無視し処理を続け手も正常に受信できます。
(ry
> その後、正常に送受信できるので無視してるのですが、

意味が分かりません。

355 :352:2006/07/29(土) 19:55:56
解りにくかったです。申し訳ありません。
サーバー側のコードは
while( true ){
 len = recv( buf );
 if( len > 0 ) 受信したデータを処理
 else if( len == 0 ) 終了処理
 else if( len == -1 ){
 if( WSAGetLastError() != WSAEWOULDBLOCK ) 例外投げるとか
 }
}
省略させていただきましたが、このような感じです。
クライアント側で、
send( "ABC" );
とした場合、
サーバー側では、
1回目のループで正常に"ABC"と受信できました。
次のループでrecvは-1を返し、WSAGetLastErrorを見ると5が返ってくるのです。

その後、クライアント側で
send( "DEF" );
send( "XYZ" );
と送信処理を続けても、
サーバー側では二度とエラー( WSAGetLastErrorで5が返る現象 )は起きないんです。
あと、サーバー、クライアント両方でんagleアルゴリズムをオフにしています。

356 :デフォルトの名無しさん:2006/07/29(土) 20:09:33
TCPにおいて、自分→相手の回線速度が5kB/sしかないのに、1kBのデータを100msごとにsendしたらどうなる?
↑をやると当然どこかおかしくなると思うけど、どんな対策が可能?

357 :デフォルトの名無しさん:2006/07/29(土) 20:10:56
ソケット関係ないエラーでしょ。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/windows_sockets_error_codes_2.asp

358 :デフォルトの名無しさん:2006/07/29(土) 20:12:29
>>356
send()のエラーハンドリングをちゃんとやる。

WSAENOBUFS
ENOBUFS

359 :デフォルトの名無しさん:2006/07/30(日) 02:52:09
おかしくなるって・・・ならんやろ
sendが戻ってこないか、EWOULDBLOCKかのどっちかじゃね?

360 :デフォルトの名無しさん:2006/07/30(日) 10:28:59
処理の遅いクライアントを作ってテストしたら理解した。
sendが長時間ブロックされることもありうるのね…

361 :デフォルトの名無しさん:2006/07/30(日) 12:32:17
クライアントが処理するまではいつまでもブロックされるのが当然だと思うが

362 :デフォルトの名無しさん:2006/07/30(日) 13:05:43
それは違う。

363 :デフォルトの名無しさん:2006/07/30(日) 13:16:50
非同期ソケットなら

364 :デフォルトの名無しさん:2006/07/30(日) 13:38:11
非同期とノンブロッキングの違いがわかってないアホ発見

夏だなぁ・・・

365 :デフォルトの名無しさん:2006/07/30(日) 13:45:16
>>352に釣られたヽ(`Д´)ノ

366 :デフォルトの名無しさん:2006/07/30(日) 14:53:38
非同期とノンブロッキングって何が違うの?

367 :デフォルトの名無しさん:2006/07/30(日) 15:02:36
大体同じだから悩むな。

368 :デフォルトの名無しさん:2006/07/30(日) 15:05:09
非同期: 結果が別途引き渡される
ノンブロッキング: 結果を得るのに待たされない

関数呼び出しは、call/execute/returnの三つに分けられるが、
returnにexecuteの結果は含まれておらず、
executeの発行結果だけが含まれるのが非同期。
exeuteの結果は割り込みなどで別途得られる。
ノンブロッキングは、executeに時間がかかりそうなら、
「時間がかかりそうなので止めました」という結果をreturnする。

369 :デフォルトの名無しさん:2006/07/30(日) 15:09:46
嘘をつくな

370 :デフォルトの名無しさん:2006/07/30(日) 15:11:32
非同期とノンブロッキングって何が違うの?

371 :デフォルトの名無しさん:2006/07/30(日) 15:16:53
大体同じだから悩むな。

372 :デフォルトの名無しさん:2006/07/30(日) 15:17:55
>>369
>>368についてだとしたら、どのへんが嘘?
見たところ間違ってはいないと思うけど。

373 :デフォルトの名無しさん:2006/07/30(日) 15:21:13
ヒント: 夏

374 :デフォルトの名無しさん:2006/07/30(日) 15:27:43
>>372
じゃあそう思っとけばいいじゃん

375 :デフォルトの名無しさん:2006/07/30(日) 15:29:50
非同期とノンブロッキングって何が違うの?

376 :デフォルトの名無しさん:2006/07/30(日) 15:39:13
大体同じでしょ。WinsockでソケットをノンブロッキングモードにするAPIはWSAAsyncSelectなわけだし。
(asyncは非同期という意味)
文脈で使い分けるんじゃね?同期(型)通信とは言うけど、ブロッキング通信とは言わない。

377 :デフォルトの名無しさん:2006/07/30(日) 15:40:47
同期/非同期は名詞。
ブロック/ノンブロックはサ変動詞。

378 :デフォルトの名無しさん:2006/07/30(日) 15:55:32
>>372
どこがって、もう説明全体がイカサマ。

379 :デフォルトの名無しさん:2006/07/30(日) 17:03:14
え、使うよ→ブロッキング通信

380 :デフォルトの名無しさん:2006/07/30(日) 17:15:45
ノンケだってくっちまうんだぜ

381 :デフォルトの名無しさん:2006/07/30(日) 18:14:53
>>378
じゃあ正しい説明書いてみたら
絶対にあーだこーだと言い逃れして書かないのは分かってるけど

382 :デフォルトの名無しさん:2006/07/30(日) 18:21:32
>>379
あまり使われてはないようだ@Google

"同期通信" の検索結果 約 38,200 件
"非同期通信" の検索結果 約 56,700 件
"ブロッキング通信" の検索結果 約 400 件
"ノンブロッキング通信" の検索結果 約 1,190 件

383 :デフォルトの名無しさん:2006/07/30(日) 18:23:20
>>381
ググレカス

384 :デフォルトの名無しさん:2006/07/30(日) 18:29:40
FIO(S)NBIOで、同期かつノンブロッキングに出来るわな。

同期/非同期と
ブロッキング/ノンブロッキングは別の概念。

同期&ブロッキング
非同期&ノンブロッキング
同期&ノンブロッキング
は普通に使う。

Winsock関係やBSD socket関係のAPIにはないけど、
非同期通信で、受け側でブロッキングってのもある。
例えばHTTPでは、非同期かつブロッキングのプログラムを書く事が多い。


385 :デフォルトの名無しさん:2006/07/30(日) 18:30:50
>>383
ほらね。
ぐぐった説明が正しいという保証は?

386 :デフォルトの名無しさん:2006/07/30(日) 18:35:21
>>381
もう論理がめちゃくちゃなんだが、大きく違うところは受信の場合だな。

ブロッキングモードとノンブロッキングモードで大きく動作が異なるのは
受信すべきデータが到着していない場合。この場合、ブロッキング
モードはデータの到着を待つが、ノンブロッキングモードではすぐに
呼び出したAPIを抜ける。
受信すべきデータが到着している場合は、両者とも同じ動作をする。
ノンブロッキングモードだからといって「非同期に」データを読み取る
わけではない。

つか、マニュアル読めばわかるだろうが。

387 :デフォルトの名無しさん:2006/07/30(日) 18:37:37
>>384
えーと、今は非同期とノンブロッキングの違いの話をしているんですが。

388 :デフォルトの名無しさん:2006/07/30(日) 18:40:09
>>384
> 非同期通信で、受け側でブロッキングってのもある。
それって、受け側では同期通信とみなしてるってことでは?

389 :デフォルトの名無しさん:2006/07/30(日) 18:40:16
非同期とノンブロッキングは同じものだと勘違いしてる馬鹿はまだいるの?

390 :デフォルトの名無しさん:2006/07/30(日) 18:41:02
大体同じだから悩むな。

391 :デフォルトの名無しさん:2006/07/30(日) 18:44:14
もう何がなんだかよく分からんが、

同期/非同期は概念。
ブロッキング/ノンブロッキングは手段。

でFA。

392 :デフォルトの名無しさん:2006/07/30(日) 18:45:52
お前らひょっとして「同期呼び出し」とか「関数がブロックする」とかの
意味もわからんかったりするのか?

393 :デフォルトの名無しさん:2006/07/30(日) 18:46:03
>>386
>>368と全然矛盾してないじゃん。
しかもあんたのは非同期はまったく説明できてない。


394 :デフォルトの名無しさん:2006/07/30(日) 18:50:10
>>393
ノンブロッキングモードでデータが到着しているときにrecvしたらどうなる?

395 :デフォルトの名無しさん:2006/07/30(日) 18:52:52
>>393
いや矛盾してるでしょ。
それに個人攻撃したいだけならよそでやってね。

396 :デフォルトの名無しさん:2006/07/30(日) 18:56:31
>>394
データ返すでしょ。
それは>>368と矛盾してないでしょ。
そのケースは説明してないだけで。(自明だからかな?)

397 :デフォルトの名無しさん:2006/07/30(日) 18:58:43
>>396
それなら>>368の説明で納得して終わりでいいんじゃないの?
てか、君わかってる人?わかってない人?

398 :デフォルトの名無しさん:2006/07/30(日) 18:59:04
>>395
具体的にどこが矛盾しているの?
たぶんそれを説明するとあなたの勘違いしている部分がはっきりすると思う。

399 :デフォルトの名無しさん:2006/07/30(日) 19:00:08
>>386
> もう論理がめちゃくちゃなんだが、大きく違うところは受信の場合だな。

どこが違うのか具体的に説明してね。

400 :デフォルトの名無しさん:2006/07/30(日) 19:01:17
>>398
矛盾してないなら、>>368>>386も正しいってことだよね。
で、それ以上このスレで何をしたいわけ?

401 :デフォルトの名無しさん:2006/07/30(日) 19:01:59
>>386の一行目は違うんじゃないの?

402 :デフォルトの名無しさん:2006/07/30(日) 19:02:44
粘着ウザ。
ってか、お前>>368なんだろ?いい加減にしとけよ。

403 :デフォルトの名無しさん:2006/07/30(日) 19:03:44
>>386は良く理解してない人だから、
勢いで書いちゃったんでしょう。あまり追い詰めるな。

404 :デフォルトの名無しさん:2006/07/30(日) 19:06:16
ほらよ。

同期/非同期は概念。
ブロッキング/ノンブロッキングは手段。

でFA。

405 :デフォルトの名無しさん:2006/07/30(日) 19:11:22
自作自演の香りが

406 :386:2006/07/30(日) 19:14:46
まあ冷静になって>>368を読み直したら、確かにめちゃくちゃは言い過ぎた。
すまん。

俺がひっかかったのは「時間がかかりそうなら」というくだり。
ノンブロッキングの場合は、「時間がかかりそうかどうか」で処理が異なることはない。
「時間がかかるかもしれないので」ノンブロッキングにするというなら話はわかる。
じゃ、俺はこの話から抜けるから。

407 :386:2006/07/30(日) 19:17:08
言い忘れた。
俺の認識も>>404とほぼ一緒だから。
非同期とノンブロッキングが同じという主張をしたいわけではない。

408 :デフォルトの名無しさん:2006/07/30(日) 19:29:01
2チャンネルとは思えないすがすがしいエンディングw
>>386 GJ


409 :デフォルトの名無しさん:2006/07/30(日) 22:08:55
あんましよくわかってないんだけど
ブロック/ノンブロックってのはAPIの関数実行に
必要な時間が可変か(ブロック)、わりと短い時間で固定か(ノンブロック)ってことで
同期/非同期ってのは相手処理が完了する時刻や
データ到着時刻と同じように影響するか(同期)そうじゃないか(非同期)
ってことでいい?

410 :デフォルトの名無しさん:2006/07/30(日) 22:44:35
非同期とノンブロッキングって何が違うの?
誰かもっと具体的に説明して

411 :386のまとめ:2006/07/30(日) 22:55:37
369 :デフォルトの名無しさん :2006/07/30(日) 15:09:46
嘘をつくな

378 :デフォルトの名無しさん :2006/07/30(日) 15:55:32
>>372 どこがって、もう説明全体がイカサマ。

386 :デフォルトの名無しさん :2006/07/30(日) 18:35:21
>>381 もう論理がめちゃくちゃなんだが、大きく違うところは受信の場合だな。
〜中略〜
つか、マニュアル読めばわかるだろうが。

395 :デフォルトの名無しさん :2006/07/30(日) 18:52:52
>>393 いや矛盾してるでしょ。
それに個人攻撃したいだけならよそでやってね。

397 :デフォルトの名無しさん :2006/07/30(日) 18:58:43
>>396 それなら>>368の説明で納得して終わりでいいんじゃないの?
てか、君わかってる人?わかってない人?

400 :デフォルトの名無しさん :2006/07/30(日) 19:01:17
>>398 矛盾してないなら、>>368>>386も正しいってことだよね。
で、それ以上このスレで何をしたいわけ?

402 :デフォルトの名無しさん :2006/07/30(日) 19:02:44
粘着ウザ。 ってか、お前>>368なんだろ?いい加減にしとけよ。

406 :386:2006/07/30(日) 19:14:46
まあ冷静になって>>368を読み直したら、確かにめちゃくちゃは言い過ぎた。
すまん。

412 :デフォルトの名無しさん:2006/07/30(日) 23:07:04
>>400>>402は俺だけど。

ってか、この手の粘着、ほんとウザいわ

413 :デフォルトの名無しさん:2006/07/31(月) 00:05:38
あーあ、区別できてないバカが切れちゃった

414 :デフォルトの名無しさん:2006/07/31(月) 20:16:59
linux使ってます。
struct sockaddr_inのsin_portに0を指定してbindした際、実際にどのポートが使われたか
調べるにはどうすればいいのでしょう?

実行後にsin_portに入るかと思ったんだけど、入ってない・・・

415 :デフォルトの名無しさん:2006/07/31(月) 20:25:04
うろ覚えだが getsockname とかそんなのじゃないの。

416 :デフォルトの名無しさん:2006/07/31(月) 20:44:58
>>415
できました!
ありがとうございます!

417 :デフォルトの名無しさん:2006/08/01(火) 08:16:45
Winsockで質問です。
10秒間にsendを100回とか大量に呼んでしまうとrecvが70回〜程度しか成功しません。

これってどうにかなりませんか?

418 :デフォルトの名無しさん:2006/08/01(火) 08:48:21
>>417
プロトコルはTCP? データは全部受信できているの?
なんか、送受信バッファとかsendの結果とか、チェックすべき項目がある気がする。

419 :デフォルトの名無しさん:2006/08/01(火) 09:09:12
プロトコルはTCPです。データは70回〜程度しか受信できていないです。
1秒間に1回sendを呼ぶとかなら全部受信できるんですが。。

単にsend呼ぶ回数が多すぎて失敗してるってことですかね?
仕事行ってきます(Winsockは初体験なんで戸惑い気味…

420 :デフォルトの名無しさん:2006/08/01(火) 09:19:21
>>419
いや、データが全部受信できているかって言うのは、「recvの回数」では分からないんだが。
recvの回数は、必ずしもsendの回数と同じになるわけではない。
単純に回数にこだわるのではなく、TCPの仕組みや、send/recvの送受信バイト数・エラーチェックなどを
見直してみると良いのでは?

421 :デフォルトの名無しさん:2006/08/01(火) 15:52:54
受信したデータの中身を見てみれば?
極端なことを言えば、100バイトのデータをsendを100回やって送ったとき、
recvは1回で100バイト受信したりすんべ?

422 :デフォルトの名無しさん:2006/08/01(火) 19:50:52
バイトの境界は保持されない

って文言みたことある?

423 :デフォルトの名無しさん:2006/08/01(火) 22:54:50
>>417
TCPはストリームプロトコルだから、
データの連続性は保障されてるけど、境界は保障されないよ

"This is a pen"


424 :デフォルトの名無しさん:2006/08/01(火) 22:55:32
まさかエンター押すときシフトに小指が当たってjaneが暴走するとは思わなかった・・・もういいや

425 :デフォルトの名無しさん:2006/08/01(火) 23:00:06
>>419
とりあえず受信サイズを全部足す

426 :デフォルトの名無しさん:2006/08/01(火) 23:11:30
今どんな気持ち?
        ∩___∩                     ∩___∩
    ♪   | ノ ⌒  ⌒ヽハッ    __ _,, -ー ,,    ハッ   / ⌒  ⌒ 丶|
        /  (●)  (●)  ハッ   (/   "つ`..,:  ハッ (●)  (●) 丶   今、どんな気持ち?
       |     ( _●_) ミ    :/Shift+Enter:::::i:.   ミ (_●_ )    |      ねぇ、どんな気持ち?
 ___ 彡     |∪| ミ    :i        ─::!,,    ミ、 |∪|    、彡____
 ヽ___       ヽノ、`\     ヽ.....:::::::::  ::::ij(_::●   / ヽノ     ___/
       /       /ヽ <   r "     .r ミノ~.    〉 /\    丶
      /      /    ̄   :|::|    ::::| :::i ゚。     ̄♪   \    丶
     /     /    ♪    :|::|    ::::| :::|:            \   丶
     (_ ⌒丶...        :` |    ::::| :::|_:           /⌒_)
      | /ヽ }.          :.,'    ::(  :::}            } ヘ /
        し  )).         ::i      `.-‐"             J´((
          ソ  トントン                             ソ  トントン


427 :デフォルトの名無しさん:2006/08/03(木) 22:15:59
>>426の引かれっぷりは異常

428 :デフォルトの名無しさん:2006/08/05(土) 05:24:43
hoshu

429 :デフォルトの名無しさん:2006/08/05(土) 20:36:13
一つのTCPコネクションがあってクライアント側とサーバ側両方から
同じプロトコル(リクエスト、レスポンス)を送信するって設計、問題あるでしょうか?
例えばクライアントはHELOリクエスト投げるし4XXレスポンス返すみたいな
サーバも同じようなことをする

430 :デフォルトの名無しさん:2006/08/05(土) 21:27:10
>>429
既存のオープンシステムとの連携を行うのであれば、そのオープン
システムが公開している規約に沿った形で電文の遣り取りを行う必要が
あるが、サーバー・クライアント双方を自前で作成するのであれば、
どのような会話手段を用いても問題ないと思う。

簡素な設計が一番。

431 :デフォルトの名無しさん:2006/08/06(日) 00:58:19
>>429
IRCがそれに近い。
しかしどのレスポンスがどのリクエストへの応答か判断するのが厳密にやるとむずい。

432 :デフォルトの名無しさん:2006/08/06(日) 01:10:42
>>429
問題ない
暗号化は忘れるな


433 :デフォルトの名無しさん:2006/08/06(日) 01:13:46
なんで暗号化・・・

434 :デフォルトの名無しさん:2006/08/07(月) 13:13:56
>>419
ソース晒せ


435 :デフォルトの名無しさん:2006/08/07(月) 13:20:51
>>429
問題ない。

リクエストかレスポンスか?
どのリクエストに対するレスポンスか? (トランザクションIDなど)
簡単に区別がつくようにしておいた方がいい。

それから接続状態の初期化にともなう処理について
よく考察した方がいいと思う。

436 :デフォルトの名無しさん:2006/08/09(水) 19:06:27
このスレを知らずに「すれ立てるまでもない質問はここで」スレのほうに
下のような質問をしたところ、「Content-Length ヘッダがあればそれを頼りに、
なければ接続が切れるまでがコンテントだぞ」と回答をいただきました。
その後、どうすれば接続が切れたことを確認できるのかわからなくて
もう一度質問したところお返事をいただけなかったので、今度はこちらの
スレでお尋ねすることにしました。
どなたか教えていただけるとうれしいです。

> 339 :デフォルトの名無しさん :2006/08/06(日) 22:14:15
> "Get /index.html HTTP/1.1"のような要求メッセージを送信して html の内容を
> 受け取るプログラムを作っています。
> 一応できましたが、タイミングによって途中までしか取得できないことがあります。
> マイナーな言語なのでソースをお見せして調べていただくことはできませんが、
> その原因がおわかりになる方がいらっしゃいましたら、どうぞご教示ください。


437 :デフォルトの名無しさん:2006/08/09(水) 19:13:25
一応ソース見せて。

438 :デフォルトの名無しさん:2006/08/09(水) 19:16:44
>>436 「接続が切れる」というと語弊があるけど、
read とか recv が 0 を返してきたらそこで受信できるデータは終わり。


439 :436:2006/08/09(水) 19:25:54
read や recv といった関数はないんです。
受信用の関数は受信した長さが返ってくるんですが、何も受信するものがなくなったあとは、
0ではなくその直前に受信したときの長さと同じ数値が返ってきてしまうんです。
でも考えてみれば、同じ数値が返ってきたときを終わりだと考えればいいですね。
やってみます。ありがとうございました!
(他の方法があれば教えてください)

440 :デフォルトの名無しさん:2006/08/09(水) 19:39:42
だから何の言語だよ
それわからなきゃどうしようもねえよ
ソース出せ

441 :デフォルトの名無しさん:2006/08/09(水) 19:47:59
>>439
それじゃあ基本的にはその関数を作ったトコに聞くしかないよ。
ここで聞いて答えが返ってくると思う神経がよくわからない(←不要な人格攻撃)


442 :デフォルトの名無しさん:2006/08/09(水) 19:49:46
>>440
うるせーよ、ソース坊

443 :デフォルトの名無しさん:2006/08/09(水) 19:57:36
アフォな実装にアフォな実装で対応しようとがんばってる感じ。
せっかくTCP/IPは標準化されているのにわざわざ殺してる。

444 :436:2006/08/09(水) 20:33:00
>>443
私が使っているのはTCP/IPを利用するための関数ですよ。
簡単に利用できるように作られた関数だと思うので、実装が悪いのではなく
知識・能力の不足が原因だと思います。

>>440
ソースはご勘弁を。
言語に縛られない一般的な方法をお聞きしたかったんです。
C/C++ の方法でもいいんですけど。


445 :デフォルトの名無しさん:2006/08/09(水) 20:43:06
>441
そんなこと言ったらこのスレの存在意義が…(ry ww

446 :デフォルトの名無しさん:2006/08/09(水) 20:55:30
なんか、わけ分からん。
ソースをそのまま出すのではなく、抜粋するなり、言語名を答えるなりすれば良いのに。
必要だと指摘されている情報を出さずに、答えだけを要求するとは。
スレの存在意義を言うのなら、その前に義務を果たせ。

>>444
言語に縛られない一般的な方法…。 readやrecvじゃだめなんでしょ?
疑似言語みたいにすれば良いのか?
とはいっても、マイナーな言語でのライブラリとやらに対応できるか分からないな。
C/C++の方法が適用できるのかも分からん。

>>439
> 同じ数値が返ってきたときを終わりだと
って、バイトストリームの途中で偶然同じバイト数を2回受信したときはどうするんだ?

447 :445:2006/08/09(水) 21:30:50
>446
ちょ・・・オレは444じゃないぞー

448 :436:2006/08/09(水) 22:16:35
やっぱりそのままは載せられないので、内容のわかる形にして下に書きます。
---------------------------------------------------------------------
timeout(変数) = 5000

条件分岐@{[ネットワーク初期化の関数]を実行し、その返り値が0なら終了}
条件分岐@終了

条件分岐A{[ネットワーク接続を開く関数]を実行し、その返り値が真なら
以下の処理を実行/偽なら終了}
  [文字列を送信する関数(リクエストメッセージを送信)]を実行する
  待ち時間100ms

  ループ
    starttime(変数) = [コンピュータ起動後の経過時間を返す関数]

    条件分岐B{[受信可能なデータの状態を返す関数]を実行し、その返り値が
    Raw Data を示していれば以下の処理を実行し、そうでなければ終了}
      receivedsize(変数) = [データを受信する関数し受信サイズを返す]
                         ↑ 5000Byteずつ受信
      待ち時間100ms
      data(変数) = data + 受信データ
    条件分岐B終了

    elapsedtime(変数) = [コンピュータ起動後の経過時間を返す関数]- starttime
  ループ終了(receivedsize < 5000Byte または elapsedtime > timeout の場合に終了)

  [ネットワーク接続を閉じる関数]を実行する
条件分岐A終了

data内の文字列を表示
終了

449 :デフォルトの名無しさん:2006/08/09(水) 22:43:16
情報処理技術者の試験勉強してたときのことを思い出して
頭が痛くなってきたw

450 :デフォルトの名無しさん:2006/08/09(水) 23:07:46
簡単に利用できるように作られた関数がネットワークとCの流儀に合ってない感じ。
ぶっちゃけ、その簡単に利用できるように作られた関数を作った香具師はネットワークのスキルの無いクズだと思うよ。

ネットワークと言うかTCP/IPスタックの実装に依存するから、Cだからこれとか標準的な物は無いよ。
ネットワーク機能自体が歴史的にBSD系のUNIXでCで実装されてきたので、BSD系のTCPスタックの実装例が世の中には豊富。

なんとなくリングバッファが実装出来てなくていちいち受け取りにいく必要が有る悪寒。

451 :デフォルトの名無しさん:2006/08/10(木) 00:01:18
>>444
> 簡単に利用できるように作られた関数だと思うので、実装が悪いのではなく

根拠あるのか?

452 :デフォルトの名無しさん:2006/08/10(木) 01:51:58
>>451
初心者用の言語とかじゃないのか?
つーか、そんなことを問い詰めても解決しないだろ?

453 :デフォルトの名無しさん:2006/08/10(木) 06:19:59
>>452
つーか、そんなこと逝っているやつを問い詰めても解決しないだろ?

454 :デフォルトの名無しさん:2006/08/10(木) 06:45:18
数年後







そして未解決のまま、その事件は時効を迎えることになる。

455 :446:2006/08/10(木) 09:09:31
>>447
そうか、すまん。でも、煽るようなカキコはやめれ。

>>436>>448
あやしいと思うのは、2つ。
まず、サーバーのレスポンスが遅いときがあるんじゃないの?
>>448の処理に「待ち時間100ms」とあるから、送受信の関数はおそらくブロッキングしないのだろう。
データを受信するループも、100ms待ちながら、受信関数を繰り返しているし。
"timeout"の値がいくつかは分からないが、レスポンスが遅ければ当然タイムアウトしてループは終了する。

次に、データの受信サイズ。
ループの終了判定を5000バイトより小さい場合としているのが気になる。
データがこまぎれになって送信されてきた場合は、正しく受信できないのでは。
ネットワークのことも考慮すると、5000バイトを一回で受信するんだ、
と考えないほうが良いと思う。

ということで、まずは以下のことを確認してみるとよいのではないかと。
1.その関数群の仕様を再度確認
 パラメータや返ってくる値、ブロッキング、受信データの待ち方
 >>448の状態だとネットワークと親和性が無いような感じだから、もう一度見直してみるといいと思う
2.現状のプログラムでタイムアウトの処理を確認
 タイムアウト処理をコメントアウト、あるいはデバッガで実行
3.データの受信サイズを確認
 デバッガで実行、あるいはそれぞれの受信サイズを記録できるように一時的に修正
4.待ち時間や受信データサイズの見直し
 100msや5000バイトって、どこから出てきた数値?

2.と3.は、>>436の事象が発生しやすい環境で確認。
とりあえずは、これで。

456 :446:2006/08/10(木) 09:21:47
連投すまん。
読み返してみたら、「サーバーのレスポンスが遅いとき」の説明が
よく分からん文章だった。
>>448の条件分岐3で、受信可能なデータの状態を返す関数の返り値がRaw Data
(おそらくは、これがデータ受信を示す)になるまでに時間がかかった場合に
タイムアウトする、ということで。
待ち時間100msも、謎なことは謎だが。

457 :デフォルトの名無しさん:2006/08/10(木) 11:20:21
>>436が言語も環境も言わない時点でなんとも

458 :デフォルトの名無しさん:2006/08/10(木) 12:29:21
>>439
受信するものがなくなったことを検知するための方法を他にも列挙せよ。

459 :436:2006/08/10(木) 18:03:53
>>455-456
わかりやすくまとめていただけてうれしいです。
今職場なのでまだ確認していませんが、3の問題のような気がしてきました。
帰ったら早速調べてみます。

>>458
それがわかっていれば質問はしません。


460 :デフォルトの名無しさん:2006/08/10(木) 18:27:08
基礎的なことでスマン
send() したパケットが、分割されて recv() されることが有りえるんだよな?

461 :デフォルトの名無しさん:2006/08/10(木) 18:28:57
>>460
あり得る。
MTUという言葉を調べろ

462 :436:2006/08/10(木) 19:39:44
帰宅して早速いろいろ確認したところ、原因がわかりました。

> 受信用の関数は受信した長さが返ってくるんですが、何も受信するものがなくなったあとは、
> 0ではなくその直前に受信したときの長さと同じ数値が返ってきてしまうんです。

と書きましたが、返り値の確認方法が間違っていただけでした。
全てのデータを受信した後はちゃんと0が返って来るのに、その確認がうまくできていませんでした。

>>455さんのアドバイスを読んで気付くことができました。
他のみなさんもどうもありがとうございました。


463 :446:2006/08/10(木) 19:59:40
Oh...
まあ、良いか。早めに解決できてよかったね。

464 :デフォルトの名無しさん:2006/08/10(木) 22:57:59
>>462
死ね!

465 :デフォルトの名無しさん:2006/08/10(木) 23:09:38
死ね厨乙

466 :デフォルトの名無しさん:2006/08/11(金) 01:52:08
Linuxのソケットについて、質問させてください。
accept()によって得られるTCPソケットのディスクリプタから、今のTCP状態を知る方法はないものでしょうか?

送信側からデータを送り終えた後のFINを検知して、受信側で出来るだけ早くclose()する
(=FINを送ってコネクション終了を相手にも伝える)ことを考えています。
そこで、TCPの状態がCLOSE_WAITならば直ちにrecv()とclose()を呼ぶ、という処理が実現できれば
いいかなと思いまして。

データを受信したものの、まだrecv()で吸い上げていないソケットを優先的に取り扱うなど
応用も利くと思うのですが、いかがでしょうか。

467 :466:2006/08/11(金) 02:00:03
>> 466
補足です。
この質問をする前にnetstatコマンドのソースを見てみたのですが、/proc下のTCP情報が
入ったファイル(すみません、名前を忘れました)をsscanf()でパースして、現在の状態を取得していました。

確かにそれでも良いのですが、ファイルオープン〜サーチ〜sscanfとコストがかかりそうなので、
もうちょっと別な、直接的な方法は無いかと思って聞いた次第です。

468 :デフォルトの名無しさん:2006/08/11(金) 08:47:31
>>466
う〜ん。ブロッキングのrecv()を発行して待つとか、select()で待つとかじゃあダメなの?

ディスクリプタからTCP状態を取得する方法は思い浮かばないんだけど、もし出来たとして、
どのタイミングでソケットの状態を見に行くんだろう?

469 :デフォルトの名無しさん:2006/08/11(金) 15:24:07
>>466
なんでそんなことしたいのかよくわからんけど、
どうせ残りのデータは吸い上げないといけないんだから、
>>468 が言うようにひたすら recv() しまくって、
データがなくなったら即 close() でいいんじゃないの?

470 :466:2006/08/12(土) 01:26:37
すみません今仕事が終わったので、お二方の書き込みをようやく拝見できました。

>>468 >>469
返答ありがとうございます。

実は組み込みLinuxがターゲットのため、できるだけメモリ節約をしたかったからなのです。
送信が終わっているのにいつまでもコネクションを開いておくのは、受信バッファぶんのメモリが無駄になりますので。
かといってどんどんrecv()してしまうのも、メモリを浪費してしまいますし・・・。
(別モジュールへの橋渡しを担う部分のため、別モジュールの様子を伺いながらrecv()したデータを転送しなければならないのです)

というわけで、せせこましいですがポーリング用のスレッドを使ってFIN_WAITのソケットを潰して行こうと考えたわけです。
でも、どうも無理っぽいですね。色々と調べてまわったのですが見つかりませんでした・・・。

471 :466:2006/08/12(土) 01:52:09
せっかくですので、今日調べて分かったことを書いておきます。
すでにご存知であれば無視してください。間違っていたら指摘してもらえると嬉しいです。
いずれもLinux(2.6.11で動作確認)についてです。

1. backlogは「3way handshakeが終わり、データ通信可能になったコネクション」の保持可能な最大数を指定する。
2. 最大値はメモリ搭載量によって変化する。通常のPCだと1024だが、32MBのメモリだと128になっていた。
3. backlog内のコネクションは、accept()で取り出すまでに受信バッファサイズぶんのデータ通信を進めている。
 (その後はaccept()〜recv()するまでウィンドウサイズに0を載せたACKを返し続ける)
4. backlogを超えるコネクション開設要求(SYNのこと)が届いた場合、SYN+ACKを返すものの後に届くACKやデータは全て無視する。
 (データが届いても意味のないSYN+ACKを再送し続ける)
5. 受信バッファサイズをsetsockopt()で指定する場合、listen()前に指定しておかないといけない。
 (listen()後やaccept()の後に指定しても、パケット上のWin値は変わらないことを確認)

上記のうち特に4.が問題で、クライアント側とサーバー側とでTCP状態のずれが発生してしまうことが分かりました。
実際に確認してみたら、確かにSYN+ACKを不用意に返していました・・・。

また5.も問題でして、これはつまり同じlisten()からaccept()したソケットの受信バッファは全て同じ値になってしまう、
言い換えると動的に受信バッファサイズを変えることができないことが分かりました。

というわけで、メモリ節約のために
「listen()前はbacklogを小さく&受信バッファを小さめにしておいて、accept()してから大きくしよう」
と思っていたのですが、出来ませんでした。

backlog指定を小さくするとコネクション異常でクライアント側はエラーになってしまいますし、
ウィンドウサイズを小さくするとその後の通信が細くなってしまいますし。
これは痛かったです。

472 :デフォルトの名無しさん:2006/08/12(土) 08:24:26
>>470
組み込み系はよく知らないのだけれども。
何と言うか、送信側〜>>466が作っているプログラム〜別モジュールの間の
流量のバランスが取れていない感じがする。
backlogを超えるコネクション要求が来たり、別モジュールの方が動作が遅そうだったり。
全体の流量、負荷を一回見直してみると良いのでは。

473 :デフォルトの名無しさん:2006/08/12(土) 09:34:15
>>471
>  (listen()後やaccept()の後に指定しても、
> パケット上のWin値は変わらないことを確認)

すぐに反映されないだけでしょ?
window size指定しているわけじゃないから。


474 :デフォルトの名無しさん:2006/08/12(土) 10:28:58
>>471
> 上記のうち特に 4. が問題で、クライアント側とサーバー側とで TCP 状態の
> ずれが発生してしまうことが分かりました。

別にずれてはいないよ。サーバー側がクライアントからの ACK を無視してるだけ。

つまり通常の状態で、クライアントが ACK を送信してそのパケットがサーバーに
届いていない状態と同じ。

サーバー側は、(自分がドロップしているんだけど) ACK が届かないので、SYN+ACK
を再送しているのであって意味がないわけではない。

そのうちキューが空けば、クライアントからの ACK を受理して、双方ともに
ESTABLISH になるけど、空かない間は SYN+ACK の再送を繰り返してそのうちあきら
めて、RST を投げて終了する。

手元の Linux だと、

| tcp_synack_retries (integer; default: 5)
| passive な TCP 接続の SYN/ACK セグメントで再送を試みる最大数。
| この数値は 255 よりも大きくすべきではない。

で、この再送回数を制御できるみたい。

お使いのプロトコルスタックで使えるかどうかはわからんけど、調べ
てみては? ただし、システムで一律の値になるから気をつけて。

475 :デフォルトの名無しさん:2006/08/12(土) 10:30:09
(... 続き ...)

ただ、>>472 も書いてる通りメモリ容量が厳しい状況でガンガンコネ
クション要求が来る状況がいまいちよくわからない。

ルーターなんかを作ってて本当にそういう状況になるなら出来合いの
プロトコルスタックなんか捨てて自分で実装するべきだと思う。

476 :466:2006/08/12(土) 21:41:41
今仕事から帰ってきました。うわ、皆さんありがとうございます。

>>473
いえ、その後もずっと反映されなかったのです。
20MB弱のデータを流してみて、accept()後のデータもEtherealでずっと追ってみたのですが変わりませんでした。
同じ書式でもlisten()前に記したsetsockopt()は有効になっているのですが・・・。
(複数人で同じソースを見直したので、(全員の目がふし穴でない限り)コーディングミスではないと思います)
でも、同じソースでもVxWorksだとすぐにウィンドウサイズが変わっています。
皆さんのLinuxだとaccept()後のウィンドウサイズって変わります?
# 書いてて気付いたのですが、もしかすると8KB→64KBといった大きい方への変更がダメなのかもしれない。

>>474
確かに、到着するパケットによる動作はお互い正常に動いていることは分かります。
ただ、もともと無視するSYNならわざわざSYN+ACKを返す必要は無いと思うんですよね。
クライアント側に「あ、コネクション張れた?」みたいな余計な期待を抱かせないで済みますし。(変な表現ですみません)
(このクライアントの誤解が後述する問題を生むことになりますし)

それならはじめからSYN+ACKなどを返さず、無視するなりRSTを返した方が良いと思うのですが、474さんはどう思います?
あ、ひょっとして再送エラーに至るまでの時間が(無視するより)短くなることを期待して返している??

あと、tcp_synack_retriesも教えていただいてありがとうございました。
実はこのパラメータは知っていたのですが、サーバー側のリトライを増やしても
先にクライアント側でエラーが発生してしまいますので、今回は使えませんでした。他にもTCPを使うモジュールもありますし。
言い忘れていましたが、クライアント側でエラーを起こしてもいけない、という条件があるのです。

477 :466:2006/08/12(土) 21:43:18
(続き)
で、
>>472, >>475
なのですが、実はこの「がんがんコネクション要求が来る状況」って簡単に起こりうることなんですよ。

まず、次のようなケースを考えます。
クライアント側にデータ送信を担うキューがあって(プリンタに対するスプーラをイメージしてもらうと分かりやすいです)、
色んなアプリがそのキューにデータを投げ込む状況を考えたとします。
ただし、このデータはlisten()の時点で既に受信バッファで受信し切れてしまうほどのデータサイズだと仮定してください。
そのキューは、サーバーに対してデータを1つ1つ別コネクションで送ります。複数をパラレルに送信することはありません。
サーバーはデータを受信したら低速なデバイス(例えばフロッピーディスクなど)に書き込む処理を行います。

さて、このときキューはアプリからもらったデータをsend()で順次送信するわけですが、
サーバー側の受信サイズが大きいためも、accept()される前の時点でデータを送信し切ってしまいます。
すると「全てのデータは送信できた」とクライアントは判断しますので、close()をコール、つまりFINを送ります。
close()したということは、クライアントのTCPにとってはデータを無事送信できたことに他なりませんので、
次のデータを送信開始します。
以降はその繰り返しです。
このように、「close()できないコネクション要求がどんどん来る」という状況が
簡単に発生することが分かってもらえると思います。
(すみません、まだ続きます)

478 :466:2006/08/12(土) 21:44:06
(続きその2。これで終わりです)
更に、やがてサーバー側listen()のバックログを使い切ってしまいます。
しかしここでもサーバーはSYB+ACKなんて甘い言葉を返すものですから、
クライアントはデータを送信し始めてしまいます。で、送信エラーが発生します。
こうなると、もはや当初目的としていた「データは1つずつ順番に送る」という状況は崩れ去っているわけです。

というわけで、TCPでこの状況を回避するためにはlisten()時の受信バッファサイズを抑えておいて
クライアントに送信未完了のままKEEP ALIVEさせておくしかないと思います。
(どうか「アプリ層でコントロールシーケンスを付ければ良いじゃない」とかは言わないでくださいね。
それが出来ていたらこんなに苦労はしないのですから・・・)

やたら長くなってしまいました。すみません。
もしつっこみどころがあれば言ってください。

479 :466:2006/08/12(土) 21:51:35
>>476-478

うわぁ、読み返してみたら何て読みにくい・・・。

皆さん、ごめんなさいごめんなさい・・・

480 :デフォルトの名無しさん:2006/08/12(土) 23:41:50
> ただ、もともと無視するSYNならわざわざSYN+ACKを返す必要は無い

そうするとクライアントは SYN が届いていないと思って、SYN を再送してくる。
サーバー側の都合のリトライをクライアント側に依存するのはちょっとおかしい
と思う。

> RSTを返した方が良いと思う

まあ、私も個人的には受け入れ能力がないんだからさっさと接続を拒否しろよな
と思う。特に Windows 系のクライアントは connect() で固まると GUI まで固ま
る作りの奴が結構いるから、とっととエラーにでもなってくれたほうがいいと思う。

で、要するに一回の送信で終わるぐらいのデータを送るのに毎回コネクションを
張ってるってことなの?

なんか、無理やりな状況作って TCP の実装がおかしいと言ってるだけのような気
がするけど…。

UDP を使うとか、コネクション張ったままにするとかはできないの?

481 :デフォルトの名無しさん:2006/08/13(日) 01:19:58
>>476
「backlogに入った状態」を無益なものというか、
「それは接続する気がないくせに無駄だ」考えに基づいて、
後から屁理屈をこねているように思う。

listen backlogに入った接続要求というのは、
接続をしてあげる予定だからこそ、拒絶しないのです。
それを「それくらいなら拒絶してくれた方がいい」というならば、
backlogの長さを0にすればいいんです。

いやサーバ側は変えられないんだということであれば、
クライアント側でタイムアウト処理を行いましょう。

482 :466:2006/08/13(日) 01:24:14
素早い返答ありがとうございました。今日は私もすばやく返信します。

>>480
> サーバー側の都合のリトライをクライアント側に依存するのはちょっとおかしいと思う。

この視点は抜けてました。参考になります。

> で、要するに一回の送信で終わるぐらいのデータを送るのに毎回コネクションを
> 張ってるってことなの?

そうなんですよ。
何10MBという大きなデータが送られてくる場合もあるのですが、一番小さなサイズが10KB程度なので、場合によっては先の状況に陥る可能性があるわけです。
可能性があるものについては目を瞑るわけにもいかず・・・。

> なんか、無理やりな状況作って TCP の実装がおかしいと言ってるだけのような気がするけど…。

いや、すみません、TCPがおかしいと言っているわけではないんです(SYN+ACKを除いて)。
・・・でも、読み返すとそうとしか取れないような表現になってますね。読みにくいし。
素直にあやまります。すみませんでした。

個人的には重箱の隅の問題だとは思っているのですが、一般にはよくある話だったりしたら
怖くて、色々と書いてしまいました。

> UDP を使うとか、コネクション張ったままにするとかはできないの?

使いたいです!そうしたいです!
そうしたいのですが、クライアント側というのがWindowsの(ほぼ)基本機能なので
どうにもなりません・・・。アプリの設計問題をいかにTCPにカバーさせるか、という
手段しか持てないんですよ。納期まであと3日ですし・・・。


483 :デフォルトの名無しさん:2006/08/13(日) 11:12:18
>>481
> それを「それくらいなら拒絶してくれた方がいい」というならば、backlog
> の長さを0にすればいいんです。

君、論点がずれてる。backlog を超えた接続要求はもう接続できねーと言うもんだ
から拒否してもいい。昔の実装はそうなってた奴も多い。ただ Linux の実装はし
ばらくしたら空くかもしれないのでリトライしてるだけ。これは、backlog を 0
にすればいいとか言う問題じゃないよ。

484 :デフォルトの名無しさん:2006/08/13(日) 11:13:13
>>482
要は、アフォなクライアントがガンガンデータ送ってくるからどうすれ
ばいいの? って話かな。

まともにやるなら、クライアント側で SO_LINGER でも設定してもらえ
ばいいんだけど、そうはいかんザキなんだろうな。

送り元が流量も考えずに送りつづけるんだからサーバー側でスプール
作ってクライアントに追いつくようにガンガン recv() しまくるしかな
いと思うよ。(低速デバイスへの書き込みは別スレッドもしくは別プロセ
スでまたーりやればいい。)

> 個人的には重箱の隅の問題だとは思っているのですが、一般にはよく
> ある話だったりしたら

普通はあまりない。まともな技術者ならガンガン送るときにいちいちコ
ネクションを張るなんていう発想はしない。

> クライアント側というのがWindowsの(ほぼ)基本機能なので

ちなみにこれ何?

> 納期まであと3日ですし・・・。

おいおい…。


485 :デフォルトの名無しさん:2006/08/13(日) 12:17:33
なんか簡単にDoSで落せそうなサーバだな。

486 :デフォルトの名無しさん:2006/08/13(日) 14:02:17
windowsの基本機能って意味わからんな
winsockはwindowsの基本機能という観点からすれば
UDPもTCPでコネクション張りっぱなしも超基本機能なわけだが

487 :466:2006/08/13(日) 21:46:29
今仕事から帰ってきました。うわ、うわ、皆さんありがとうございます。

>>481
すみません、入れ違いになってしまいました。
backlogを0にすると「全てが拒絶していないようで拒絶している」という状態になり、クライアント側で送信エラーが発生してしまいますので・・・。ごめんなさい。
って、backlogが0でもlisten()は動くんですか?

屁理屈っぽくなっていたのは、本当にすみません。

> 要は、アフォなクライアントがガンガンデータ送ってくるからどうすればいいの? って話かな。

あはは、そんな感じです。鋭いですね。そしてガンガンrecv()したいです。メモリさえあれば・・・

> 普通はあまりない。まともな技術者ならガンガン送るときにいちいちコネクションを張るなんていう発想はしない。

これを10年前に作成した方々に言ってあげてください。
そこからクライアント、サーバー共に複数機種に派生し、それらとも互換性を
持つように動かさないといけないので、今更変えられないのです。

> ちなみにこれ何?
> windowsの基本機能って意味わからんな (>>486

すみません、ここだけは勘弁してください。組み込み系で分かりやすいところなので、確実にバレます。

> なんか簡単にDoSで落せそうなサーバだな。

確かに。でも落とさない方が良いと思いますよ。
製品仕様(やイメージ上)LAN内でのみ使うものですので、いきなり
「犯人はこの中にいる!」状態になってしまいますから。
(でもSYN Flood防御のカーネルオプションは付けてます)

488 :466:2006/08/13(日) 22:04:02
そういえば、listen()前に指定したSO_RCVBUFが意図していた動きと違っていることに気付きました。

socket(7)でも書いてあったのですが、SO_RCVBUFに指定した値は内部では2倍されて持つことになるんですね。見落としていました。
キャプチャデータを見ていると、どうもaccept()前に受信できているサイズが指定バッファサイズよりも大きいことに(今更)気付きまして・・・。
想定している最小データサイズだと、クライアント側で送信エラーが発生することが分かりました。

どうしよう、これ以上受信バッファを狭めるとaccept()後のスループットが落ちてしまう・・・
>>473さんへの返答でも書いたのですが、Linuxって受信バッファを途中で変えられないみたいなので、さて、困りました。

あぁ、>>484さんの、

> おいおい…。

が重くのしかかります。ぉぃぉぃ…。

489 :デフォルトの名無しさん:2006/08/13(日) 23:13:32
そのクライアントは connect() の ECONNREFUSED はリトライするけど、
send() のエラーはリトライできないってことか?

プロトコルスタックを書き換えるぐらいしか思いつかない…。

490 :466:2006/08/15(火) 20:41:51
>>489

send()はエラーを出していると思います。
ただ、もともとが「エラーを出してはいけない」という要求なので・・・。
しかも、同じクライアント(PC)側ソースをWinXPで使用すると大丈夫で、Win98だとエラーになるといういやらしさ。

本当、プロトコルスタックの書き換えくらいしか思いつきません。

さて、ここまで皆さんありがとうございました。
皆さんからのそもそも話は非常に参考になりました。問題だけを追っていたら気がつかなかったことなので、ありがたかったです。
学んだことは次の製品(orファームアップデート)で活かそうと思います。

ありがとうございました。一応、ここで質問の流れは切ろうと思います。
(どうも製品仕様として収まりそうなので・・・)
何かコメントいただいた方には返信するようにしますが、こちらからの新展開はないと思います。

では皆さん、暑いので身体には気をつけてください。
ここまでのご助言、本当に感謝しています。
それでは。

491 :デフォルトの名無しさん:2006/08/16(水) 09:36:41
>>461
いまねっとプログラム作ってます
書いてあることがわかりました


492 :デフォルトの名無しさん:2006/08/19(土) 08:35:05
C言語のソケットのサンプル等でよく

struct sockaddr_in sin;

のような記述を見かけるのですが、最初の struct はどういう意味でしょう?単に

sockaddr_in sin;

と書いた場合との違いは何なのでしょうか?

493 :デフォルトの名無しさん:2006/08/19(土) 09:01:10

死ねば良いと思うよ。



494 :デフォルトの名無しさん:2006/08/19(土) 10:29:21
>>492
それはネットワークプログラム特有の質問じゃなく、C言語の記述方法の質問だ。
スレ違いだから、C言語関連スレに行け。
さらにCについての疑問がなくなるまで、そうなだ・・・・最低半年はROMってろ。


495 :デフォルトの名無しさん:2006/08/19(土) 10:52:52
そうなだで台無しw

496 :デフォルトの名無しさん:2006/08/20(日) 12:40:46
windowsのC++でプログラムしています。
ソケット接続でサーバーと接続しているのですが、
サーバー側が接続を切ったかどうかわかる方法ってありますか?
recvとかsendする前に接続が維持されているかチェックしたいのですが・・・

497 :デフォルトの名無しさん:2006/08/20(日) 14:02:14
プロトコルは?

498 :496:2006/08/20(日) 14:18:05
>>497
tcpです。

499 :デフォルトの名無しさん:2006/08/20(日) 15:18:28
とりあえず、>>1のFAQは読んだかい?

500 :デフォルトの名無しさん:2006/08/20(日) 15:22:31
C++でWsaAsyncSelectでTCPクライアントサーバを作っています。
クライアントから
・"-LOGIN test\n\n"
・"-PASS hoge\n\n"
・"(省略)\n\n"
とほぼ同時に送信した場合、サーバ側のFD_READをつかまえたときに
recv()の結果が "-LOGIN test\n\n-PASS hoge\n"
などとなってしまうことがあるのはTCP通信の仕様上仕方ないとは思うのですが
"\n\n"までが1つのデータとして受け取って、それ以降は次のデータとみなす
スマートな方法はないでしょうか。


501 :デフォルトの名無しさん:2006/08/20(日) 16:01:24
宿題スレがお似合いだ

502 :500:2006/08/20(日) 16:52:29
かなりコードが汚いですが自己解決しました
class CDataRecv {
char szBuf[MAX_SEND_LENGTH*2];
char szRecvBuf[MAX_SEND_LENGTH];
public:
char szLineBuf[MAX_SEND_LENGTH];
CDataRecv(void){szBuf[0] = szRecvBuf[0] = szLineBuf[0] = '\0';}
int Recv(SOCKET s){
int nRecvLen;
char *dem;
char szTemp[MAX_SEND_LENGTH];

nRecvLen = recv((SOCKET)s, (LPTSTR)szRecvBuf, sizeof(szRecvBuf)-1, 0 );
if(nRecvLen<0){return -1;}
szRecvBuf[nRecvLen]='\0';
strcat(szBuf,szRecvBuf);
dem = strstr(szBuf,"\n\n");
if(dem == NULL){
return 0;
}
strcpy(szTemp,dem+2);
dem[0] = '\0';
strcpy(szLineBuf,szBuf);
strcpy(szBuf,szTemp);
return strlen(szLineBuf);
}
};


503 :デフォルトの名無しさん:2006/08/20(日) 22:05:22
うへぇ、汚ねえなw
最近C#ばっかりでC++をだいぶ忘れてるが、さすがにもうちょっと
スマートに書けないか?

recv(受信データ);
バッファ += 受信データ;
while (バッファに"\n\n"あり) {
 コマンド = バッファの先頭から最初の"\n\n"の手前まで;
 バッファ = 最初の"\n\n"の直後からバッファの最後まで;
 ディスパッチ関数(コマンド) ← コマンド処理;
}

概念的にはこんな感じで。


504 :デフォルトの名無しさん:2006/08/21(月) 09:31:41
strcpyは避けろって言われ(ry

505 :デフォルトの名無しさん:2006/08/21(月) 10:58:19
C♯, C#相談室 Part33
http://pc8.2ch.net/test/read.cgi/tech/1153537081/
でも相談したんですが、特定の言語の話じゃないので、
こちらに書かせてもらいます。マルチになりますがすみません。

今、ストリーミングを再生・録音するソフトを作りたいと思っています。
できればC#かVB.NETで。。。
「Windows Media Player」や「Net Transport」もあるけど、
単純な機能だけに絞った再生・録音ソフトを自分で作りたいんです。
参考になる書籍とかサイトを教えていただければありがたいです。
開発を始めたら、一緒に情報共有していきたいです。(・∀・)

506 :村人A:2006/08/21(月) 12:14:54
>>505
>単純な昨日だけに絞
るなら,Google先生が必要なことは全部教えてくれると思うよ。

507 :デフォルトの名無しさん:2006/08/21(月) 12:22:49
ネットワークプログラミングとの関連が不明だけど… rexec でもするってことなのか?

508 :デフォルトの名無しさん:2006/08/21(月) 14:12:34
ネットワークというよりプロトコルの話だな。
おそらくmmsがらみのことになるんだろうが、
MSは仕様公開してないから厳しいだろう。
単にファイルに落とすだけなら
ヘッダー+WAVEデータでOKだから
UDPでパケット全部蓄積してから
ヘッダーに足しこんでローカル保存だな。
再生はわからんw


509 :デフォルトの名無しさん:2006/08/21(月) 14:14:33
Windows 98 SE
Visual C++ 6.0

CAsyncSocketを使ってCreate();,Connect(SOCKADDR, sizeof(SOCKADDR));してるんだが
OnConnectのコールバックが数秒で来るホストと1分以上来ないホストがあるんだが、来ない場合のタイムアウト
処理はWM_TIMERとかを組み合わせて自前で行う必要があるの?

お願いします教えてください。


510 :デフォルトの名無しさん:2006/08/21(月) 18:12:54
MFCはまったくわからないので力になって上げられませんごめんなさい。


511 :デフォルトの名無しさん:2006/08/22(火) 00:57:57
ソケットで繋ぎさえすればサーバ側、クライアント側関係なくデータの送受信ができるんですか?
たとえばクライアント側からデータを送って、データ受信確認のための応答をサーバ側に渡したいんですが
この場合でもソケットを繋ぎ直さずに送ることってできるんでしょうか?

512 :デフォルトの名無しさん:2006/08/22(火) 02:14:38
ガタガタ言ってねえで実際に書いてやってみろや

513 :デフォルトの名無しさん:2006/08/22(火) 05:09:35
>>512
亀田乙

514 :デフォルトの名無しさん:2006/08/22(火) 13:57:52
誰か翻訳して。

515 :デフォルトの名無しさん:2006/08/22(火) 15:08:59
Mr./Ms. Kameda and tiredness.

516 :デフォルトの名無しさん:2006/08/23(水) 01:00:07
>>511は、まずはTCPとUDPのプロトコルのお勉強から始めましょうということで

517 :デフォルトの名無しさん:2006/08/24(木) 11:28:59
>>511
とりあえずnetcatでも使ってみればいいんじゃね?


518 :デフォルトの名無しさん:2006/08/24(木) 16:22:53
例えば
HELLO
ときたら
OK
と返すプログラムが作るとしたら
HELLO
test
と送られてきた場合
いったん全部読むのが普通ですか?



519 :デフォルトの名無しさん:2006/08/24(木) 17:05:25
>>518
日本語でおk




場合によりけり。


520 :デフォルトの名無しさん:2006/08/24(木) 19:04:59
送られてきた奴を全部よみこむんでしょうか?
一行ずつ解析してフラグを作るの?

521 :デフォルトの名無しさん:2006/08/24(木) 19:17:54
送られてきたものが全部とはかぎらない
1からやりなおしてくれ

522 :デフォルトの名無しさん:2006/08/25(金) 09:26:37
>と返すプログラムが作るとしたら
"そういうのを作るプログラム"を作りたいのねw


523 :デフォルトの名無しさん:2006/08/25(金) 11:08:32
みなさんはどうゆう風に書いてるのでしょうか?
ネット上にあるのはサンプルばかりでわかりません。
どうやって終わりだと判断するのでしょうか?
例えば
HELLO\n
ときたら
recvして読み込んで
OK\n
と返すのですが
HELLO\nの後にもなにかくるかもしれないじゃないのですか?
でも なにもこないのにrecvすると止まらないですか?

524 :デフォルトの名無しさん:2006/08/25(金) 11:10:38
プロトコルを決めた人に聞け!

525 :デフォルトの名無しさん:2006/08/25(金) 11:27:00
>>523
> HELLO\nの後にもなにかくるかもしれないじゃないのですか?

来ないから安心してw


526 :デフォルトの名無しさん:2006/08/25(金) 12:03:46
確実に全部読み込むにはどうすれば?
コード書いてくれません?
recvの戻り値でこない事とかわかります?

527 :デフォルトの名無しさん:2006/08/25(金) 12:11:36
HELLO\n
もう来ないよープンプン\n

と送れ!

528 :デフォルトの名無しさん:2006/08/25(金) 12:15:35
>>526
> 確実に全部読み込むにはどうすれば?
> コード書いてくれません?
> recvの戻り値でこない事とかわかります?

recvが0を返すまで

http://www.nakka.com/lib/inet/func.html#recv関数

529 :デフォルトの名無しさん:2006/08/25(金) 12:16:05
まずSTDINで同じことするプログラムを書けるようになってから来い

530 :デフォルトの名無しさん:2006/08/25(金) 12:21:45
>>528
え? recv() の戻りが 0 だからといって後続のパケットが無いわけじゃないのでは?

だからこそプロトコル毎に終端子とか、転送量を事前に通達するなんていうことが必要になるわけで…

531 :デフォルトの名無しさん:2006/08/25(金) 12:29:27
だからみなさんどうやってるんですかorz...

532 :デフォルトの名無しさん:2006/08/25(金) 12:31:47
普通は「これが来たらあとはその先何送ってきても無視ね」というような約束に
しておく。


533 :デフォルトの名無しさん:2006/08/25(金) 12:33:37
>>531
というか先にプロトコルを提示しなよ。

→HELLO\n
←OK\n

で終りなの?

ちなみに\nじゃなくて\r\nって明記した方がいいよ。


534 :デフォルトの名無しさん:2006/08/25(金) 12:36:10
>>531

上のほうのレス見ても、何を知りたいのかよくわからん

パケットを全て読み込みたいのなら、>>528の通りrecv()を戻り値が0になるまで繰り返すだけ。
まぁたぶん知りたいこととは違うんだろうけど。


535 :デフォルトの名無しさん:2006/08/25(金) 12:37:01
ネットワークにOSは関係ないから明記する必要はプロトコルとしては無いんじゃないか?

536 :デフォルトの名無しさん:2006/08/25(金) 12:38:49
CRLF と書くのが語弊がなくすっきりするのかもね

# RFC822 の line-feed があいまい杉。 後方で CRLF 出てくるから問題ないけど

537 :デフォルトの名無しさん:2006/08/25(金) 12:41:45
プロトコルが提示されてないから何でもありだな
本当に\nだけかもしれない

538 :デフォルトの名無しさん:2006/08/25(金) 12:43:33
>>532 のルールを無理矢理 >>533 にあてはめるとすれば
・\n が来るまではパケットが続く
・\n 以降のパケットは無視
ってところだな

recv() 1回目 "O" まで
しばらく recv() == 0
recv() 2回目 "K\n"

なんていう状況がありえるわけだし

539 :デフォルトの名無しさん:2006/08/25(金) 12:46:41
>>535
低能は黙ってろ。

540 :デフォルトの名無しさん:2006/08/25(金) 12:53:08
>>538
細かいところ突っ込むけど
ブロッキングならrecv()がデータ来るまで止まるし
ノンブロッキングなら-1かなにかでエラー返すんじゃなかったかな?
0を返すのはソケットがクローズされた時じゃない?

541 :デフォルトの名無しさん:2006/08/25(金) 12:54:32
\nであるべきところを\r\nでも通るように作ってグダグダになるくらいなら
\n出なければ正しく通らない低能の方がまとも。

542 :デフォルトの名無しさん:2006/08/25(金) 12:55:46
>>540
あ 0 は close か?
-1 (or ERROR) との比較と勘違いしてたかも

543 :デフォルトの名無しさん:2006/08/25(金) 13:06:49
すみません

HELLO\n
ときて OK\nと返すプログラムなんですけど
もしかしたら
HELLO\n
TEST\n
とくるかもしれない時がある時に
recvで確実に全部読み込む方法が知りたかったのです。
これは \n\nがきたら終了というふうにすればいいのですね?



544 :デフォルトの名無しさん:2006/08/25(金) 13:09:39
それでみなさんに聞きたいのですが
\n\n がきたら終了という処理をみさんはどのように書きますか?

while (1)
{
n=recv(s, buf, sizeof buf);


}

この場合
if (buf[n - 1] == '\n' && buf[n - 2] == '\n')
が普通ですか?





545 :デフォルトの名無しさん:2006/08/25(金) 13:14:23
>544
かならずしも末尾に \n\n が来ることが保証できない
最悪 "\n" "\n" と2回に分断される可能性もある。

なので、自前でバッファリングし、recv() で得られた文字列を連結しつつチェックする

546 :デフォルトの名無しさん:2006/08/25(金) 13:16:31
>>543-544
> これは \n\nがきたら終了というふうにすればいいのですね?

そんな風に尋ねられても…\n\nってどこから出てきたの?
プロトコルで規定されてるの?

> この場合
> if (buf[n - 1] == '\n' && buf[n - 2] == '\n')
> が普通ですか?

nが1だったらまずいね
recv()で受信したデータは別のバッファに突っ込んだらどうかな

547 :デフォルトの名無しさん:2006/08/25(金) 13:17:12
かぶった…OTL

548 :デフォルトの名無しさん:2006/08/25(金) 13:35:48
クライアントが健全であるとは限らないしね。
HELLO
まで送ってだんまりかも

よってタイムアウト処理を組み込まざるを得ない。

549 :デフォルトの名無しさん:2006/08/25(金) 13:45:15
こんなのスルーでよくね?w

550 :デフォルトの名無しさん:2006/08/25(金) 15:02:49
タイムアウトってやっぱりスレッド使うの?

551 :デフォルトの名無しさん:2006/08/25(金) 15:34:34
シグナルでもおk

552 :デフォルトの名無しさん:2006/08/25(金) 15:59:56
シグナルとは?
WinAPIにそんなのあったっけ

553 :デフォルトの名無しさん:2006/08/25(金) 19:01:22
あるあるwwwwwwwwwww
ねーy・・・あるあるあるwwwwwwwww


ま、一番カンタンなのはrecv()用にスレッド作るか
非同期にしてメッセージ受け取るかしたらいいんじゃないですか

554 :デフォルトの名無しさん:2006/08/25(金) 20:32:00
コード書いてくれませんか?
さっぱりです。

555 :デフォルトの名無しさん:2006/08/25(金) 20:45:09
では次の質問どうぞ。

556 :デフォルトの名無しさん:2006/08/25(金) 21:16:52
質問です
なんで今日は初歩的な話題でこんなに盛り上がってるんですか?

557 :デフォルトの名無しさん:2006/08/25(金) 21:21:56
>>554に間じれスすると
上の方にも書いてたように stdinで同じことできるくらい
ストリームについて基本的な理解がないと
コードうpしてもさっぱりだとおもうよおもうよ

558 :デフォルトの名無しさん:2006/08/25(金) 21:34:23
stdin はできますよ。
ようするに recv で 1byteづつ取り入れて\nがきたらリターンする
ラッパーを作ればいいのですね?
fgets()のように

559 :デフォルトの名無しさん:2006/08/25(金) 21:40:02
四の五の言わんと自分のソース晒したらええねん!

560 :デフォルトの名無しさん:2006/08/25(金) 22:21:12
>>558
"HELLO\n"程度のプロトコルならそれでいいでしょ。
一バイトごとにrecvしな。ただしタイムアウト付きで。

561 :デフォルトの名無しさん:2006/08/25(金) 22:24:17
stdin, stdout で同じ事やろうとしても関数&環境次第でバッファリングされちまうな。

562 :デフォルトの名無しさん:2006/08/26(土) 00:05:50
ルータ的にバッファリングしてまとめて1パケットで送ってくれたほうが負荷が小さい。
鯖とか作って大量にデータ送るような用途ではネットワーク負荷を考慮して実装しないと痛い目をみるよ。
ルータは処理しきれなくなるとあっさり捨てるから、送り直しで大変なことに成る。

無視するかどうかチェックするわけが有るので、大量にパケット送りつけるとDoS成立。

563 :デフォルトの名無しさん:2006/08/26(土) 10:19:13
>>562
Nagleアルゴリズムって知っているか?

564 :デフォルトの名無しさん:2006/08/26(土) 10:47:42
いいかげんソース書いてよな!!

565 :デフォルトの名無しさん:2006/08/26(土) 10:54:45

1対1のオセロ作ってるんですけど
対戦用のスレッドを作って順番に
send recvしていますが、これはおかしいですか?

send() // 自分が置いたコマの位置を送信
recv() // 相手が置いたコマの位置を受信
send()
recv()

送信用 受信用スレッドを作るのが宝石ですか?


566 :デフォルトの名無しさん:2006/08/26(土) 10:58:13
>>564
いいかげんにしろよ

567 :デフォルトの名無しさん:2006/08/26(土) 11:10:54
sendとかrecvの話なんだけど、
windowsのテルネット(telnetのポートではなく各サービスのポートで)で接続すると
送られてきた奴は即座に表示してくれるし
入力された文字は即座に送ってくれる。
あれってどうやってやってるの?
常に相手から送られる繰るのを監視して、
自分のも常に送られるようにしてる。
しかも相手が切断したら即座にテルネット側も気づいて切断されたって表示する。
どうやってるの?

568 :デフォルトの名無しさん:2006/08/26(土) 11:33:28
↓BSDのtelnetのそこんところの部分 process_rings()
http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb.cgi/src/contrib/telnet/telnet/sys_bsd.c?rev=1.12&content-type=text/x-cvsweb-markup

*ring*()ってのは、eventのring bufferを操作する関数。(ring.c)

main loopはtelnet.cのtelnet()

569 :デフォルトの名無しさん:2006/08/26(土) 12:18:14
>>565
別におかしくないと思うけど、それだと相手からのデータ待ちの時に
ユーザーから操作ができなくなるので、受信スレッドを別に作ること
が多い。

>>567
・キー入力 ⇒ send()
・recv() ⇒ 画面表示

の2個のスレッドを作るなり、OS によってはキー入力とネットワーク
の監視を同時にできるものもあるからそれ使うなりすればいい。

570 :デフォルトの名無しさん:2006/08/26(土) 14:33:08
あほなの?

571 :デフォルトの名無しさん:2006/08/26(土) 14:57:34
受信データ落ちまくりだと、受信データが送られてくるまで一切操作出来ずに反応が無くなるアプリケーションって多いよね。
このアプリケーション作ったPG、もうアフォかと。

572 :500:2006/08/26(土) 20:42:38
>>500ですがしばらく忙しくてコーディングする時間が取れなかったんですが
今日は時間が空いたので考えてみました。
とりあえずWsaAsyncSelectを使用して
class CDataRecv{
  string sBuffer;
public:
  SOCKET s;
  int Recv(){
    int nRecvLen;
    char szTemp[SERVER_SEND_LENGTH+1];
    nRecvLen = recv((SOCKET)s, (LPTSTR)szTemp, SERVER_SEND_LENGTH, 0);    
    if(nRecvLen < 0) return -1;
    szTemp[nRecvLen] = '\0';
    sBuffer += szTemp;
    return nRecvLen;
  }
(続く)

573 :デフォルトの名無しさん:2006/08/26(土) 20:46:17
(続き)
  char *Output(char tmp[]){
    char *szBuf;
    char *p;
    int nLen;
    nLen = sBuffer.size();
    szBuf = new char[nLen+1];
    strncpy(szBuf, sBuffer.c_str(), nLen);
    szBuf[sBuffer.size()] = '\0';
    p = strstr(szBuf,"\r\n");
    if(p==NULL){
      sBuffer = szBuf;
      tmp = NULL;
      delete(szBuf);
      return tmp;
    }
    p[0] = '\0';
    sBuffer = p+2;
    strcpy(tmp,szBuf);
    delete(szBuf);
    return tmp;
  }
};
のクラスを作って、FD_READを受け取った時点で一度Recv()を実行し、
Output()がNULLを返すまで受信メッセージの処理を繰り返すというやり方で
今のところ落ち着きました。まだまだ良いアイデアを教えていただけたら嬉しいです。

連レスすみmせn

574 :500:2006/08/26(土) 20:55:41
(追記)
Connect()とかClose()ももちろんあるんですがここでは関係ないので省略しました。
わかりにくくてすみません。
あと>>502で\n\nになっていたデリミタですが\r\nに変更したので上のコードでは
\r\nになっています。

スレ汚し本当に申し訳

575 :デフォルトの名無しさん:2006/08/26(土) 21:59:55
HTTPのプロトコルがわかりやすく説明されているサイトってないでしょうか?
RFCは難解で難しすぎます

576 :デフォルトの名無しさん:2006/08/26(土) 22:12:09
>>575
つ http://pc8.2ch.net/php/

577 :デフォルトの名無しさん:2006/08/26(土) 23:37:28
>>575
Studying HTTPと@IT

578 :デフォルトの名無しさん:2006/08/27(日) 06:06:14
>>573
ネットワークと関係ないけど、
せっかくstring使ってるんだからstringのメソッド使うともっとシンプルに書けると思う

579 :デフォルトの名無しさん:2006/08/27(日) 10:04:46
HTTPのプロトコル自体が複雑で難しいと思うよ。
読めばさらりと分かるほど簡単じゃない。簡単と思うような説明は難しいことは省かれてるだけ。
HTTP/0.9の実装とかね。

580 :デフォルトの名無しさん:2006/08/27(日) 11:05:05
> 簡単と思うような説明は難しいことは省かれてるだけ。

だからまずはそういう説明が欲しいって言うことなんだろ。

難しいところを省くのも芸のうちだよ。

581 :デフォルトの名無しさん:2006/08/27(日) 13:50:55
それはRFCのイントロを読めばいいから。

582 :デフォルトの名無しさん:2006/08/27(日) 14:36:36
>>581
RFC読んだけど細かい部分は読んだ奴の勝手な解釈になるってことがわかった
仕様書は細かい部分までしっかり書こうな>RFC書いた馬鹿


583 :デフォルトの名無しさん:2006/08/27(日) 16:17:35
今複数人で同時にチャットできるソフトを作ってますが
やはり各ソケット毎にスレッドを作るのが当たり前ですか?


584 :デフォルトの名無しさん:2006/08/27(日) 16:19:27
>>583
チャット如きにスレッド使わないと思います。

585 :デフォルトの名無しさん:2006/08/27(日) 16:21:31
>>583
何か>>500っぽい書き方だな。
まあ、とりあえずは一回自分で作って試してみては?

586 :デフォルトの名無しさん:2006/08/27(日) 16:37:25
>>583
スレッド使わないと糞ソフトですがww


587 :デフォルトの名無しさん:2006/08/27(日) 16:38:10
>>584
スレッド使わないと糞ソフトですがww

588 :デフォルトの名無しさん:2006/08/27(日) 16:44:31
>>584
同意
ノンブロッキングで、来たものを全員に回すだけだしな
何か重いことやるならスレッド起こしたいが
チャット程度ならなあ

589 :デフォルトの名無しさん:2006/08/27(日) 16:52:14
スレッド使わないで
タイムアウトはどうするんだ?ww



590 :タイムアウトって何の?:2006/08/27(日) 17:00:23
>>589

591 :デフォルトの名無しさん:2006/08/27(日) 17:07:42
>>583
接続数と障害対策次第。
漏れだとソケット10個くらいならスレッド起こさない。

592 :デフォルトの名無しさん:2006/08/27(日) 17:09:22
逆にソケット1万個にスレッド割り当てるなんてこともしたくないけどね。

593 :デフォルトの名無しさん:2006/08/27(日) 17:09:49
>>585
別人です

594 :デフォルトの名無しさん:2006/08/27(日) 18:27:52
ソケットごときで糞スレ立てんな、ボケが

595 :デフォルトの名無しさん:2006/08/27(日) 18:46:56
「主に」だからいいんじゃないの?

596 :デフォルトの名無しさん:2006/08/27(日) 21:48:33
progAとprogBとで、非同期に双方向に通信したいのですが、
良いサンプルを見つけることができずに、なかなかうまく
行きません。
どこかに良いサンプルないでしょうか?
LinuxでもWindowsでもOKです。

597 :デフォルトの名無しさん:2006/08/28(月) 01:50:48
伝家の宝刀を抜いたな・・・

> なかなかうまく 行きません。

何をどれだけ試したのか書け。

> LinuxでもWindowsでもOKです。

・・・

598 :デフォルトの名無しさん:2006/08/28(月) 02:14:08
>>伝家の宝刀を抜いたな・・・
わらたw

599 :デフォルトの名無しさん:2006/08/28(月) 07:24:10
言語はなんなんだろ。
brainf*ckかwhitespaceかな。



600 :デフォルトの名無しさん:2006/08/28(月) 19:16:10
プログラムぐらい貼れよ(w

601 :デフォルトの名無しさん:2006/08/28(月) 20:51:21
>>583
チャットサーバー作って5年の俺がマジレス。
クライアントサーバー型、OSはWindowsと勝手に解釈して説明すると、

サーバー側
これはクライアントごとにスレッド作る必要はない。スレッドを作ると
かえって面倒になる。何でかというと、チャットサーバーというのは
あるクライアントから来たデータを各クライアントに配信しなければ
ならないからです。ソケットごとにスレッド立てるとその辺の制御が
めんどくさいのです(不可能というわけではない。俺も初期のころは
スレッドの勉強ついでにそういうやり方でやってた。しかし、プログラムが
やや複雑になるのでおすすめできません)。
特殊なものでない限りせいぜいチャットなんて10人まででしょうから、
パフォーマンスもへったくれもありません。堂々とselect使ってくださいw
なお、サーバ側は無理にGUIにしなくても、コンソールで十分です。

クライアント側
なんでもお好きな方法で。GUIと相性のいい非同期だと楽。


602 :デフォルトの名無しさん:2006/08/28(月) 23:04:01
クライアントなんてブラウザでいいよ^^

603 :デフォルトの名無しさん:2006/08/29(火) 01:42:28
サーバなんて ircd でいいよ^^

604 :デフォルトの名無しさん:2006/08/29(火) 07:20:11
教えて下さい
NIC2枚さしのPCで、自作クライアントアプリを動かすと、自分のPCのIPアドレス(NIC)を指定しなく
ても、下層で判断して通信してくれるようですが、
アプリケーションのほうで、通信対象となるNICの指定はできないものなのでしょうか?


605 :デフォルトの名無しさん:2006/08/29(火) 07:25:42
winsockでスレッドでrecvしてブロックしてる状態で別のスレッドからsendすると止まるんだが
どうしたらいいのだ?

606 :デフォルトの名無しさん:2006/08/29(火) 09:07:56
>>604
bind

607 :デフォルトの名無しさん:2006/08/29(火) 10:17:33
ヒント:ルーティング。

608 :デフォルトの名無しさん:2006/08/29(火) 21:00:21
>>604
> 通信対象となるNICの指定はできないものなのでしょうか?

・ソースアドレスにしたいのか、そのNICからパケットを出したいのか?
・OS

によってやり方が違う。

609 :デフォルトの名無しさん:2006/08/29(火) 21:40:36
>>605
> winsockで
> スレッドで
> recvしてブロックしてる状態で

まず、その変な日本語をどうにかしなよ。

610 :604:2006/08/30(水) 00:48:43
>>606
ありがとうございます。そのとおりでした。

また、他の質問なのですが、自作のサーバープログラム(VB6)から、これまた自作のクライアント
プログラム(VC++2005)に、TCP/IPで60000バイトのデータを、タイマーイベントを利用して周期的
に送り、クライアント側は単に受信するだけで何もしない(受信のみして捨てるだけ)ようにしたところ、
それでも、タイマー周期が30msくらい短くなると、転送がおいつかなくなるんですが、
こんなものなのでしょうか?
サーバーの送信を停止後、イーサーリアルを起動し、送信停止後、数十秒に渡ってパケットが
転送されていたのを確認しました。

あと、各送信時に送信完了を待たずに次々と60000バイトのパケットを送ると逆に大きな
遅延になったりしますか?今自宅のため確認できませんが、たしか待ちが入っていなかった
かもしれません。

cpuは共に3.0GHzでメモリも1G、イーサーネットはハブを含めて100M以上(片側のpcはギガ)
です。


611 :610:2006/08/30(水) 00:50:47
それとネットワークは3台のPCをハブで接続しただけのローカルなものです。

612 :デフォルトの名無しさん:2006/08/30(水) 01:00:21
>タイマーイベントを利用して周期的に送り
肝心の値が・・・

613 :デフォルトの名無しさん:2006/08/30(水) 01:01:12
受信も30msに一度とかじゃないだろうな?
TCP ウィンドウサイズ スロースタート とかでググってみれ。

614 :610:2006/08/30(水) 01:12:39
受信はVC++2005のMSDNのサンプルにあった非同期ソケット受信を参考にして、
受信があった場合、ReciveCallbackという関数が自動的に呼ばれる仕組みを用いています。

あと、LINKは100Mbpsになってました。

615 :デフォルトの名無しさん:2006/08/30(水) 01:30:09
>転送がおいつかなくなるんですが、
どういうこと?

616 :デフォルトの名無しさん:2006/08/30(水) 02:41:06
インターネットに60000バイトなんて連続で流したら、ルータが綺麗に捨ててくれると思うよ(w

617 :デフォルトの名無しさん:2006/08/30(水) 03:16:57
あほ

618 :610:2006/08/30(水) 07:19:41
>>615
すみません。転送がおいつかなくなるとうのは適切でないかもしれません。
ただ、受信側は受信(ReciveCallback発生)があったら、変数にコピーするのみで、データを
使って何か計算するような思い処理を行っておらず、
また、>>610にも書きましたとおり、サーバーの送信を止めると、イーサーリアルでは数十秒
に渡ってパケットが流れているため、クライアントの受信処理が遅いのではなく、パケットの
到達が遅いのではと考えたんですが....
意味不明だったらすみません。今日、会社で続きやります。


619 :デフォルトの名無しさん:2006/08/30(水) 07:26:22
>>610
> サーバーの送信を停止後、イーサーリアルを起動し、送信停止後、数十秒に渡ってパケットが
> 転送されていたのを確認しました。

これってパケット数が多すぎて表示するのに時間かかってるだけじゃ?
60000byteが秒間30回ほどの周期で数十秒となると、送信バッファ何十MBもってるんだよって話になる。

転送が追いつかない場合はsendがエラーを返すので、そのあたりをチェックすればいいと思う


620 :デフォルトの名無しさん:2006/08/30(水) 08:05:33
>>610
ん〜、「数十秒に渡ってパケットが転送」っていうのは、どういう状況だろう?
例えば、送信プログラム・Ethereal・受信プログラムのそれぞれのログ(時刻、送受信バイト数など)は、
どう対応しているのか? (>>619の言うとおり、表示にかかる時間じゃなくて、送受信の時刻そのものを確認)
パケットは、どんな種類があるのか?
MTUに分割された複数のパケットが転送されて、再送されて…、なんてことは無い?

あとは、>>619も書いているけど、sendとrecvはエラーを必ずチェックすること。
sendがエラーになっているのに、チェックしていなかったからプログラムが正常終了したと
思ってしまった、ってことが無いように。

621 :610:2006/08/30(水) 23:27:19
>>619 >620
どうもありがとうございます。
今日会社でいろいろやってみたところ、サーバーのほうが、送信完了(SendComplete)
を待たずに次々と送っていたため、サーバーアプリ上における送信したことを示す表示と、
実際の送信に時間差が生じていたようでした。


622 :622:2006/08/31(木) 21:22:11
こんばんは。
winsockを使って、
A端末⇔B端末という、UDPベースの送受信プログラムを作成しているのですが、
A→B端末はOKでも、B→A端末へのパケット送信ができません。

Etherealというパケットキャプチャリングソフトを使って調べたところ、
やはりB→A端末へのパケットがキャプチャできていないようです。

なにが、原因なんでしょうか・・・やはりプログラムなんでしょうか?

623 :デフォルトの名無しさん:2006/08/31(木) 21:27:04
ファイアウォールは?

624 :デフォルトの名無しさん:2006/08/31(木) 21:38:30
ノーd先生は?

625 :622:2006/08/31(木) 21:45:21
書き込みありがとうございます。
A端末、B端末ともファイアウォールは切断してあります。

626 :デフォルトの名無しさん:2006/08/31(木) 22:36:42
>>622
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=33221&forum=7&start=8

>ばーど 投稿日時: 2006-08-31 22:03
>す、すごい。
>そういう所もチェックしてるんですね!
>ん〜、分かりました。
>もう少し焦点を絞って、再度質問させて頂きます。

お前馬鹿だろ?

627 :デフォルトの名無しさん:2006/08/31(木) 22:47:23
勉強目的ならソース晒すのが一番

628 :デフォルトの名無しさん:2006/09/01(金) 00:16:23
udpが実装されてないtcpスタックでも使ってるとか(w
まあ今のままじゃ、エスパーが降臨しない限り誰も答えられないほどに情報が少ない。

629 :デフォルトの名無しさん:2006/09/01(金) 08:01:41
>>622
一応、>>626のリンク先を流し読みした。けど、情報少ない〜。

まずは一回、A→B→A端末の通信じゃなくて、B→A→B端末の通信が出来るかどうか、
A端末とB端末のプログラムを逆にして試してみ。pingが通っていることだし。

>>622もリンク先で言っている通り、B端末側で「Aから送信されてきたパケット内に含まれている
IPアドレスからA端末側のアドレスを取得」が、うまく出来ていないのかもしれない。
デバッガで1ステップずつ変数の中身も含めて確認してみるのも、1つの手だぞ。

630 :デフォルトの名無しさん:2006/09/01(金) 08:47:04
EtherealをAで動かしたのかBで動かしたのかくらい書け。

631 :デフォルトの名無しさん:2006/09/01(金) 19:56:12
C

632 :デフォルトの名無しさん:2006/09/01(金) 20:14:09
じゃあD

633 :デフォルトの名無しさん:2006/09/02(土) 00:49:22
>>596

ProgA,Bとも
@スレッド作成。
Aそのスレッドでは、
while(1){
recv(buf);
enqueue(buf,queue);
}
Bメインスレッドでqueueからデキューしてメッセージを解析、それに応じた処理などを行う。
sendでメッセージをおくる処理など。

※queueはキューでヒープ領域に作成してA、Bの両スレッドからアクセスできるようにしておく。
※queueはスレッドセーフにする。また、CPUリソースを消費しないようcond変数のシグナリングでwake upさせる機構を導入する。


「非同期メッセージパッシング、ActiveObject、

634 :デフォルトの名無しさん:2006/09/02(土) 07:46:38
>>605
ノンブロッキングモードを使うんだ


635 :デフォルトの名無しさん:2006/09/06(水) 03:17:53
sendするとき、やっぱりselect使って遅れるかどうか確認すべき?

636 :デフォルトの名無しさん:2006/09/06(水) 03:18:28
遅れる->送れる

637 :デフォルトの名無しさん:2006/09/06(水) 11:35:03
>>635
前もってチェックしてもいいし、sendの返り値をチェックしてもいいし。

ただ事前チェックでokでもサイズによってはsend失敗する場合もあるから、
事前チェックが必要なければ後者だけでいいと思うが。

638 :デフォルトの名無しさん:2006/09/08(金) 01:35:56
オーバーラップドI/Oだろ。
いまどきSelectでポーリングとか、ノンブロッキングで強引に突破とか、マルチスレッドでごり押しとか、ダサ過ぎ。

639 :デフォルトの名無しさん:2006/09/08(金) 01:54:46
そういうのが必要なところもあるんだけど・・

640 :デフォルトの名無しさん:2006/09/08(金) 15:25:16
それはそもそもの設計ミス

641 :デフォルトの名無しさん:2006/09/08(金) 17:28:05
大昔の人たちが残した遺産とか・・

642 :デフォルトの名無しさん:2006/09/08(金) 18:46:07
WSAAsyncSelectを使ってTCP、非同期、1対多人数のチャットを作ってます。
ダイアログでIPユーザ名ポート等を入力→ウィンドウでチャットとしたいのですが、
WSAAsyncSelectの第2引数をウィンドウの方のハンドルにすると非同期化に失敗してしまいます。
ダイアログの方のハンドルにすると成功するんですが、イベント処理させたいのはウィンドウの方なのでこれはマズいですよね・・・ 何か方法はないでしょうか。

あと、ソケットを人数分用意する方法なんですが、あらかじめ接続人数MAX分ソケットを用意するという方法しかないですよね?
(一人接続してきたらまた一つソケットを宣言みたいなのは無理なんで)

それとサーバ側もクライアントになって自分のサーバに繋ぎに行く方法にしてるんですが、まずい方法でしょうか?

初歩的な事が多いですがどなたかお願いします。

643 :デフォルトの名無しさん:2006/09/08(金) 19:43:31
いっぱいあるけど、具体的に少しでもコードだしてきた方が早いと思うよ。

644 :デフォルトの名無しさん:2006/09/08(金) 19:51:45
>>642
DialogBoxParam()

645 :642:2006/09/08(金) 20:55:46
DialogBoxParamの中身を見てたらDialogBoxで親ウィンドウのハンドルを渡していない事に気付き、
ハンドルに値が入るタイミング考えたら成功するようになりました。
これで何とかなりそうです。ありがとうございました。

646 :デフォルトの名無しさん:2006/09/08(金) 23:07:21
WinSock2の重複IOを使ってC++でネットワークの汎用クラスを作ろうとしているのですが、なかなか上手くいきません。
underflow が発生したときに、ブロックして受信を待つようなものなら簡単なんですが、ブロックせずに完了通知を待つような場合
iostreamとは相性が悪いのでしょうか。

なんか、車輪の再発明をしているような気もする。。

647 :デフォルトの名無しさん:2006/09/08(金) 23:41:50
>>638
その場合って、やっぱ通信部は別スレッドで処理すんの?

648 :デフォルトの名無しさん:2006/09/09(土) 06:51:48
オーバーラップIOってNT専用だし

649 :デフォルトの名無しさん:2006/09/09(土) 08:02:54
9598はMSも正式に切ったし、MEも今しばらくの命。

650 :デフォルトの名無しさん:2006/09/10(日) 00:30:53
http://www.microsoft.com/japan/windows/support/endofsupport.mspx

Meももう終わってるよ

651 :デフォルトの名無しさん:2006/09/10(日) 02:17:24
>>649
9598って何の事か分からなかった。
95,98なのか。もう大昔のように感じて寂しい・・

652 :デフォルトの名無しさん:2006/09/10(日) 03:43:41
大昔だろ

653 :デフォルトの名無しさん:2006/09/10(日) 04:04:37
UNIXでオーバーラップI/Oに相当するものは?
ないってことだけはないと勝手に思ってるけど

654 :デフォルトの名無しさん:2006/09/10(日) 04:51:21
aio_*

655 :デフォルトの名無しさん:2006/09/10(日) 13:55:22
>>646
受信バッファ不足や送信バッファ過多の場合にブロックするか例外をだすかしかない。

656 :デフォルトの名無しさん:2006/09/10(日) 14:04:20
シグナルで受けるというのがダサすぎる

657 :デフォルトの名無しさん:2006/09/10(日) 14:30:25
http://developers.sun.com/solaris/articles/event_completion.html
とかは、(さすがに後発だけあって)よく考えられていると思うよ。
標準的に使えるようになれば楽そうだけどね。

658 :デフォルトの名無しさん:2006/09/10(日) 20:58:46
あるサーバ/クライアントを起動時に選択できるチャットソフトがあるんですが、
サーバで起動してnetstat -aで状態を見ると、
localhost:適当なポートA→指定したポート
localhost:指定したポート→適当なポートA
という感じで接続をしています。
これはサーバ起動後、クライアントと同じ挙動をして127.0.0.1にconnectという感じで動いていると思っていいんでしょうか?

659 :デフォルトの名無しさん:2006/09/10(日) 22:05:14
>>658
思っていいですよ

660 :デフォルトの名無しさん:2006/09/11(月) 18:05:17
>>659
ども。色々納得しました。

661 :デフォルトの名無しさん:2006/09/11(月) 20:06:14
ストリームで、接続(コネクション?セッション?)を維持したままで、
相手のデータ転送が終わった事を知るにはどうすればよいのでしょうか?
バイナリー(byte)転送とテキスト(asciiか互いが共通の文字コード))転送で
その方法はどこか違うのでしょうか?
どうぞよろしくお願いします。

662 :デフォルトの名無しさん:2006/09/11(月) 20:15:24
>>661
・プロトコルを考えましょう
・テキストはMSが残した大罪

663 :デフォルトの名無しさん:2006/09/11(月) 21:00:23
>>662
kwsk

664 :デフォルトの名無しさん:2006/09/11(月) 21:39:49
態度が気に入らないので嫌です

665 :デフォルトの名無しさん:2006/09/11(月) 21:49:55
>>663
接頭辞法 とかでぐぐればでるよ

666 :デフォルトの名無しさん:2006/09/11(月) 21:59:46
>>662 ありがとうございます。ASCIIとかUTF8で転送することは(Web以外では?)特に無いですからね。
>>664 よろしければ、一緒にオレ様プロトコルを作りませんか?

667 :デフォルトの名無しさん:2006/09/11(月) 22:30:33
>>666
勘違いしてない?
OSごとの改行コードの違いを吸収するか否かだよ

668 :デフォルトの名無しさん:2006/09/11(月) 22:32:27
タイプライター的にはMSが正しい

669 :デフォルトの名無しさん:2006/09/11(月) 22:38:52
>>667 テキストで転送するときの、MSの\r\nのことですか?
>>668 結構古いことをご存知ですね。

670 :デフォルトの名無しさん:2006/09/11(月) 23:42:50
/dev/tty は UNIX にもある訳だが

671 :デフォルトの名無しさん:2006/09/11(月) 23:58:16
>>670 UNIXにもって、他にはどこにあるんですか?どういうこと??

672 :デフォルトの名無しさん:2006/09/11(月) 23:59:08
>>661
基本的にソケットには終端を付ける機能はないので、受信側で終端を検知することはできません
例えばHTTPプロトコルだとContent-Lengthというヘッダにデータサイズを乗せることで
終端検出しています
同じように送るデータにデータサイズを含めて送り、受け取った側がすべてのデータが揃ったことを
検知し、ソケットをクローズする
送り手は相手のクローズを検知し、送信が終了したことを知るといった方法しかありません
接続を維持したままでしたら、受信側にすべて届いたときになにかを送り返すようにして
送信側はrecvでブロックしておいて、受信完了メッセージ待てばいいです

673 :デフォルトの名無しさん:2006/09/12(火) 00:48:27
>>672
SOCK_SEQPACKET

674 :デフォルトの名無しさん:2006/09/12(火) 02:18:39
>>672 FTPのようなサーバー・クライアントでの対話型を考えていたので、
標準的な手法や仕組みがどうなっているのか気にかけていました。
的確は指摘には、のどにあったツッカエが取れたように嬉しいです。
ありがとうござます。
>>673 System (OS) からのメッセージは、奥が深いです。

675 :デフォルトの名無しさん:2006/09/12(火) 02:20:33
>>674
対話型なら CRLF あたりが終端子になること多いかもね

676 :デフォルトの名無しさん:2006/09/12(火) 02:50:54
>>675
テキストでの対話型(ASCIIやUTF16とかテキストデータの送受信)
なら終焉記号はそれ(\r\n)でも(0x00..0x19とか)何でもいいです。
一応オレ様プロトコルと仮定してですけど・・・・

バイナリーでの対話型(データ転送)で、終わりを明示したかったのですが、
終焉記号でやるより素直にサイズでやります。
テキストのように終焉記号じゃ無理です。

ところでシグナル?(例外?)もいいですね。

677 :デフォルトの名無しさん:2006/09/12(火) 13:20:23
普通バイナリってサイズ使うんじゃないの?w

678 :デフォルトの名無しさん:2006/09/12(火) 13:54:11
可変長にならざるをえないのなら [サイズ][data 本体.....] だろうな

679 :デフォルトの名無しさん:2006/09/12(火) 14:33:13
>>677
昔はよくエスケープシーケンスを使いましたね。

ESC EOT → お終い
ESC ESC → ESC

など。RS-232C上のプロトコルに多かった。

680 :デフォルトの名無しさん:2006/09/12(火) 15:30:16
バイナリでエスケープシーケンス?

681 :デフォルトの名無しさん:2006/09/12(火) 16:16:15
>>678 普通はまずそれが浮かびます。UTF8の可変構造も興味深いです。
>>679 参考になります。シリアル通信に目をつけるととは、先人の知恵が満載でしょう。

682 :デフォルトの名無しさん:2006/09/12(火) 17:31:18
>>680
頭悪いね

683 :デフォルトの名無しさん:2006/09/12(火) 18:40:12
>>682
バイナリでエスケープシーケンス?

684 :デフォルトの名無しさん:2006/09/12(火) 18:48:21
バイナリ列がそのままストレートにデータにはならず、エスケープ処理によって終端を区別可能にする
という策もアリだと思うけど。

具体的なデータ長が、データ転送初期段階で確定しないような場合とかね。

685 :デフォルトの名無しさん:2006/09/12(火) 18:55:33
>>684 とってもいいんだけど、それがプロトコルを策定することだと思う。
それと、「データ」だけ微妙に大きかったりして。

686 :デフォルトの名無しさん:2006/09/12(火) 19:55:40
てゆーかさ、そんなの大抵はhttpを真似る方針で良いんだよ。
多くの人に理解しやすいし説明せずに済む場合も多いし。

前出の長さ出力(テキストだからエンディアン問題なし)とか
ヘッダとボディ(データ)の区切り
長さが決まってない場合のchunk(あるいは強制切断)
それと、(厳密にはhttpじゃなくてCGIだけど)
POST時の空白や+や%等のエスケープの仕方とか。

687 :デフォルトの名無しさん:2006/09/12(火) 20:19:26
この高速大容量通信の時代に1byteづつチェックするエスケープは無しで。

688 :デフォルトの名無しさん:2006/09/12(火) 20:26:26
socket関数がどういう処理をする関数なのか覗く事って無理でしょうか。

689 :デフォルトの名無しさん:2006/09/12(火) 20:40:43
>>686 そうだ、そうだ。アイディアいっぱい集大成。
>>687 1byteといわず1bitずつチェックする方がいいと思うけど・・
今の時代とか高速大容量とか関係ないよ。
15年前はシリアルで有線
10年前はモデムで56000 bpsだったよね・・
10年後は1秒で地球何十週の速さと容量が民間へ
15年後は衛星から無線転送(GPSみたい)とかじゃないか?
それでもどこかで1byte(1bit)づつチェックすることには変わりないから。

690 :デフォルトの名無しさん:2006/09/12(火) 20:41:38
ソース見るってこと?
リナックスでもBSDでもオープンソラリスでも好きに探せば

691 :デフォルトの名無しさん:2006/09/12(火) 20:42:10
シリアル通信のエスケープといえば思いつくのはプリンタのプロトコルだが文字コードだから出来るだけでしょ

692 :デフォルトの名無しさん:2006/09/12(火) 20:45:44
>>691
ビットマップ転送になると、バイナリ流したはずですぜ。
# LP-xxxx 系だったかな?

693 :デフォルトの名無しさん:2006/09/12(火) 21:04:48
>>689
通信チップが勝手にやるのとメインCPUでぶん廻すのとは違うよね

694 :デフォルトの名無しさん:2006/09/12(火) 21:10:19
あんまり変わらないと思われ

695 :デフォルトの名無しさん:2006/09/12(火) 21:11:07
うわ、頭悪い・・・

696 :デフォルトの名無しさん:2006/09/12(火) 21:14:07
何が違うか書いてないのに会話が成立するわけなかろう

697 :デフォルトの名無しさん:2006/09/12(火) 21:15:26
うわ、頭悪い・・・

698 :デフォルトの名無しさん:2006/09/12(火) 21:20:48
まあエスケープはスマートじゃないよな
あらかじめ来るサイズが分かってたら、メモリの確保量とか受信拒否とかいろいろ出来る
よってサイズを頭に付けるのが一番効率がいい

699 :デフォルトの名無しさん:2006/09/12(火) 21:47:22
httpのmultipartの各part頭にサイズ情報が付かないのはなぜですか?

700 :デフォルトの名無しさん:2006/09/12(火) 21:59:06
>>692 その技術はネット間(クライアントとサーバ・Web)でも通じるものがきっとあるよ。
>>693 やっている事は同じだけど、感じ方が違うかな。
面倒でも自分でやるのか、面倒だから専門チップに任せるのかの違いはあっても、
チェックはしないとね。

旧来の(通信)技術を博物館や図書館のように展示しておいて欲しい。
本だと希少とか絶版とかで入手困難だと気軽に見学できない。

701 :デフォルトの名無しさん:2006/09/12(火) 22:02:33
巨大なファイルを送受するとCPUが上がるって。
蟹チップかよ!

702 :デフォルトの名無しさん:2006/09/12(火) 22:06:04
>>698
7bit JIS かわいそす

703 :デフォルトの名無しさん:2006/09/13(水) 01:51:15
>>686
それならhttpをそのまま使った方がいい。
libhttp系のライブラリ使って。

Content-Length: スタイルのやり方は、うまくいけばいいけど、
間違った「長さ」を渡された時のリカバリなど、
自前で作ると結構手間がかかる。

自作して泥沼になるくらいならエスケープの方がずっとまし。

ちなみにSolaris 2.5.1のCDE Mailアプリは、
Content-Length: があると、From行を無視して、優先して扱うので、
間違った「長さ」のメールがあるとmbox形式スプールを壊してしまった。
// From行エスケープで二文字増えたのを調整しないMUA/MTAが当時あったから。

704 :デフォルトの名無しさん:2006/09/13(水) 02:19:16
NeXTのもそうだった

705 :デフォルトの名無しさん:2006/09/13(水) 07:31:17
>>689
> 10年後は1秒で地球何十週の速さと容量
光速越えてしまいます.


706 :デフォルトの名無しさん:2006/09/13(水) 11:21:25
>>705
量子通信が実用化されてるということじゃなかろうかw

707 :デフォルトの名無しさん:2006/09/13(水) 11:36:51
粒子使う時点で光速の壁が立ちはだかります。
ここは亜空間通信でせう。

708 :デフォルトの名無しさん:2006/09/13(水) 11:43:02
亜空間通信、俺達が死ぬ前に実用してくれ!
ところで、亜空間通信でもやっぱり先頭にはデータのサイズあるのかな?

709 :デフォルトの名無しさん:2006/09/13(水) 12:21:08
無限不可能性通信が実現されれば、有限の手順など不要になるよ
もっとも亜空間通信も不可能性通信も結局はTCP/IPをカプセル化して使うんだろうけどね

710 :デフォルトの名無しさん:2006/09/13(水) 13:26:15
気のせいか、映画[the fly]を思い出した・・・・・・・

711 :デフォルトの名無しさん:2006/09/13(水) 13:42:14
あれ冷静に考えるとハエいなくてもカビやバクテリアとの合成生物になるよな。

712 :デフォルトの名無しさん:2006/09/13(水) 15:23:05
何もなくても空気と合成されてエアインチョコみたいになりそう。


713 :デフォルトの名無しさん:2006/09/13(水) 15:31:57
電送人間は転送先チューブが真空だったようなキガス


714 :デフォルトの名無しさん:2006/09/13(水) 15:55:00
じゃぁ転送完了と同時に血液・水分が沸騰して即死だな

715 :デフォルトの名無しさん:2006/09/13(水) 16:04:28
1M〜3M程度のデータをサーバーに転送する場合
httpでPOSTとかPUTとか使って送ってしまうのと、WinSockで独自プロトコルで組んでしまうのでは、どちらが効率いいでしょうか?
新たに組むほどの価値があるならばWinSockで組んでしまおうかと思うのですが、
httpdだとリジューム出来ないのが困りものです。

ちなみに、FTPは今のところ考えていません。

716 :デフォルトの名無しさん:2006/09/13(水) 16:05:17
>>715
> httpdだとリジューム出来ないのが困りものです。

出来ます。

717 :デフォルトの名無しさん:2006/09/13(水) 16:08:24
>>716
できません。

718 :デフォルトの名無しさん:2006/09/13(水) 16:22:25
アップロードでresumeか

719 :デフォルトの名無しさん:2006/09/13(水) 16:28:21
tomcat使ったwebアプリにいくらでもあるじゃん。
HTTPリクエストにRangeも指定できるし。


720 :デフォルトの名無しさん:2006/09/13(水) 16:29:16
つWebDAV

721 :デフォルトの名無しさん:2006/09/13(水) 16:57:57
>>719
>HTTPリクエストにRangeも指定できるし。
は?

722 :デフォルトの名無しさん:2006/09/13(水) 17:12:12
>>715
開発スピードはクライアント側だけ作ればいいHTTPを使ったほうが早い
通信速度はHTTPだと多少のオーバーヘッドはあるものの、全体のサイズが数Mということであれば
ほとんど変わらない

723 :デフォルトの名無しさん:2006/09/14(木) 18:37:47
位相情報を維持できないthe flyの転送装置は使い物にならんだろ

724 :デフォルトの名無しさん:2006/09/14(木) 18:50:45
クライアント側でhttpd起動して
サーバーからクライアントに向けてhttp requestすれば
resumeもできるだろうけど

725 :デフォルトの名無しさん:2006/09/14(木) 18:53:34
素直にftpかsftpをプロセス起動で

726 :デフォルトの名無しさん:2006/09/15(金) 00:27:34
C/C++ですがこちらでよろしかったでしょうか。
短い文字のチャットは勉強したところですが、
winsock,TCPで大きなファイルの送信について質問です。
linuxのサーバにも送信してみたいと思います。

「SIZEごとにfreadで読み込んで送信」というふうに考えているんですが
方針として下記のようなコードで考えていけば良いでしょうか?

while((n = fread(Buf,1,SIZE,filep)) != 0) {
  send(socket, Buf, (int)strlen(Buf), 0);
}

あとは、
・データが順番どおり届いているのか
・届いていないデータがあるのかどうか
など自分で実装しないといけないでしょうか?

ネットワーク初めてなので、自分で決まりを考えて実装するのは
ちょっと自信がありません。
・"もっと簡単な方法"や"書籍"、"参考になるHPページ"など
ありましたらよろしくお願いします。

727 :デフォルトの名無しさん:2006/09/15(金) 01:05:49
・TCPだから順番入れ代りはない。
・sendの返り値をちゃんと見ろ。

番外
・freadしただけなのに、strlen? n使えよ。

728 :デフォルトの名無しさん:2006/09/15(金) 01:21:18
<<727
>・TCPだから順番入れ代りはない。
TCPがデータの届いた順番や確認をしてくれるっていうのは、
こういうことだったんですね。

>・sendの返り値をちゃんと見ろ。
>番外
>・freadしただけなのに、strlen? n使えよ。
的確なアドバイスありがとうございます。

また何かありましたら、よろしくお願いします。

729 :デフォルトの名無しさん:2006/09/15(金) 05:56:24
the flyもある意味ストリーム転送だしな!
データとノイズ?が交じっていてもチェックできなかったようだけどさ!

730 :デフォルトの名無しさん:2006/09/15(金) 05:59:12
>>711
それい言っちゃお終いでしょ。
映画のタイトルも、「ざ・カビ」 「ざ・バクテリア」に変わっちゃうしさ。

731 :デフォルトの名無しさん:2006/09/15(金) 07:46:54
>>726
ファイルの長さを測るのなら、strlen()は避けたほうがいい。
バイナリファイルだと、途中に0があった場合、長さを間違うぞ。

732 :デフォルトの名無しさん:2006/09/15(金) 09:23:37
>>731
原因知らないと気づくまで、すごく時間が
掛かりそうですね。
すごい感謝です。

733 :デフォルトの名無しさん:2006/09/15(金) 12:11:04
read側が書いてないけどunixだとE_INTRで取りこぼしたときに再読み込みする必要あるんじゃなかったか?


734 :デフォルトの名無しさん:2006/09/15(金) 12:21:24
>>733
よく知らないことを書き込まなくていいから。
初心者が混乱するので。

735 :デフォルトの名無しさん:2006/09/15(金) 13:43:35
バイナリを扱うならvectorという便利なものがある

736 :デフォルトの名無しさん:2006/09/15(金) 13:48:17
>>734
ちゃんと書かないと取りこぼすのは本当。


737 :デフォルトの名無しさん:2006/09/15(金) 15:12:53
顔真っ赤にして必死だな 藁

738 :デフォルトの名無しさん:2006/09/15(金) 15:26:24
どっちが必死なんでしょうね^^

739 :デフォルトの名無しさん:2006/09/15(金) 16:32:28
httpだと認証垂れ流しだから、sslで包むか、ssh使った方がいいと思う。

740 :デフォルトの名無しさん:2006/09/15(金) 16:41:24
精子と合成されて ザ・精子 〜億マン精子の反逆〜


741 :デフォルトの名無しさん:2006/09/15(金) 21:17:47
>>739
認証だけ丸見えにしないようにするならDigest認証もあるよ

742 :デフォルトの名無しさん:2006/09/15(金) 22:47:52
いや今もっとも普及している高信頼の暗号法base64だ

743 :デフォルトの名無しさん:2006/09/15(金) 23:27:58
>>742
よく知らないことを書き込まなくていいから。
初心者が混乱するので。

744 :デフォルトの名無しさん:2006/09/16(土) 00:19:54
わざと言ってるようにしか見えない。

745 :デフォルトの名無しさん:2006/09/16(土) 01:46:09
受信サーバー(マルチスレッド)のタイムアウト処理をしたいのですが、
下記のソースだとどのへんにどのような処理を加えればよいでしょうか。
マルチスレッドではないノンブロッキングの方法は勉強しました。
よろしくお願いします。

    if(pthread_create(&ChildThread,NULL,Send,(void *)NULL)==0){
        //親スレッドをセットしました
        ParentThread=pthread_self();
        while(1){
            //受信処理繰り返し
            if(Rcev()==-1){
                break;
            }
        }
        pthread_kill(ChildThread,SIGINT);
        pthread_join(ChildThread,&th_return);
    }
    else{
        return -1;
    }

746 :デフォルトの名無しさん:2006/09/16(土) 05:59:01
簡単だから、Javaでやれ!

747 :デフォルトの名無しさん:2006/09/16(土) 08:32:13
>>745
Rcev()とかいう関数内でselect()したら?

748 :デフォルトの名無しさん:2006/09/16(土) 12:04:57
漏れはmd5をよく使ってる。128ビットだから現実的な時間では破れないし。

749 :デフォルトの名無しさん:2006/09/16(土) 12:09:52
>>746
マルチスレッドでタイムアウトの処理のサンプルが
見つからないのでどうしていいか全くわかりませんでした。
簡単に考えればいいんですか。

>>747
>オーバーラップドI/Oだろ。
>いまどきSelectでポーリングとか、ノンブロッキングで強引に突破とか、マルチスレッドでごり押しとか
っていうレスがあったので、マルチスレッドだとなにか特別な方法があるの
かと思ってしまいました。
Rcev()内でselectを使えばいいですか。
selectもう一回調べてみます。
ありがとうございました。

750 :デフォルトの名無しさん:2006/09/16(土) 12:12:38
CHAP最強

751 :デフォルトの名無しさん:2006/09/16(土) 12:16:16
selectはpollingじゃないですけどね。

752 :デフォルトの名無しさん:2006/09/16(土) 12:29:19
>>748
MD5興味あるんだけどさ、SHAとかもあって調べるの面倒なので教えてくれないか。
現実的な時間って、MD5で破られるのにどれくらいかかるの?
細かい事はなしでいいからさ、何ヶ月とかだったけ?

753 :デフォルトの名無しさん:2006/09/16(土) 12:34:34
http://www.cl.cam.ac.uk/~rnc1/brute.html
http://slashdot.jp/security/04/08/18/0257220.shtml?topic=28

754 :デフォルトの名無しさん:2006/09/16(土) 13:04:09
>>748
md5は8時間で敗れるぞ

755 :デフォルトの名無しさん:2006/09/16(土) 14:24:25
ライブラリ拾ってきて使うだけならどれ使っても利用の手間は変わらないんなら
素直にもっと強度の高いSHAとか選べばいいと思うんだが
なんで今MD5なんか選ぶのかな

756 :デフォルトの名無しさん:2006/09/16(土) 14:38:42
sha1は4年で敗れるぞ

757 :デフォルトの名無しさん:2006/09/16(土) 14:40:04
あくまで一般的なPCで概算した数字なので
PC性能が上がるか、スーパーコンピュータか、分散コンピュータを使うともっと短い

758 :デフォルトの名無しさん:2006/09/16(土) 17:01:26
全くの初心者がお勉強するのにいいHP教えて下さい。
C++暦4年、MFC、STLは使い慣れてます。

759 :デフォルトの名無しさん:2006/09/16(土) 17:47:46
テンプレくらい読め、くず。

760 :デフォルトの名無しさん:2006/09/16(土) 17:57:54
>>756,>>754,>>753
目安になった。さんくす。

>>757
今の性能でも破られるまで、30分ぐらいもてばいいんじゃないか?
最低限でも、せいぜい30秒は欲しいけど。
サイズにもよるけど、
今のPC性能でもxor暗号は30分ぐらいは持ってほしいけど、無理か。

761 :デフォルトの名無しさん:2006/09/16(土) 20:23:18
>>758
C+ 4年もやっててソケットプログラミングしたことないのか?

762 :デフォルトの名無しさん:2006/09/16(土) 20:28:42
>>760
まあxor暗号でも鍵の運用がワンタイムパッドなら最強だけどね

763 :デフォルトの名無しさん:2006/09/16(土) 21:02:41
>>760
ハッシュと暗号を同列に語るのはどうか

764 :デフォルトの名無しさん:2006/09/16(土) 23:31:32
ハッシュ?

なんか強い電波でも受信されましたか?

765 :デフォルトの名無しさん:2006/09/16(土) 23:41:55
>>764
MD5やSHAはハッシュだが

766 :デフォルトの名無しさん:2006/09/16(土) 23:49:20
>>761 C+ ?
>>762 ああ、それそれ。
>>763 MD5をハッシュ・キーにしてるんでしょうか。
キー生成のコストはいかがですか?
>>764 なんか強いパケットでも....

767 :デフォルトの名無しさん:2006/09/16(土) 23:51:30
>>766
そうではなく、MD5やSHAはハッシュ関数の一種
http://ja.wikipedia.org/wiki/MD5
http://ja.wikipedia.org/wiki/SHA

768 :デフォルトの名無しさん:2006/09/17(日) 00:39:05
そういえば、ウイルスを作ったり、語ったりするすれないんだね。

769 :デフォルトの名無しさん:2006/09/17(日) 02:30:35
なんでさーこうレベルの低い話が次から次へと出てくるんだろうね
いらいらするわ
夏休み終わっただろ糞がきども
さっさと寝ろ

770 :デフォルトの名無しさん:2006/09/17(日) 02:47:57
>>769 どういうのがレベルが高い話といえるのか?あ?

771 :デフォルトの名無しさん:2006/09/17(日) 03:34:20
まじめな話独自のソフトならsha1にちょっと手を加えてやればソースが流出しないかぎりほぼ解読不可能になるよ

772 :デフォルトの名無しさん:2006/09/17(日) 06:47:04
ソースを隠せば解読が難しくなると思ってる奴がはびこってるあたり確かに低レベルだな
暗号の素人が加えた「改良」のせいでかえって破りやすくなることなんていくらでもあるのに

773 :デフォルトの名無しさん:2006/09/17(日) 07:28:13
ソースを晒すより解読は面倒になるじゃん

774 :デフォルトの名無しさん:2006/09/17(日) 07:30:36
>>772
じゃあ独自のハッシュ関数で以下のハッシュが得られました
fa09
たった4桁ですどうぞ最初のパスを解読してください

775 :デフォルトの名無しさん:2006/09/17(日) 10:31:54
>>774
こういうのがレベル低いってやつか
hashからメッセージを復号することはできない
hashに対する「攻撃」は、同一のhashを生成するメッセージの発見に尽きるわけだが。
(もとのメッセージと同一である必要はない)

776 :デフォルトの名無しさん:2006/09/17(日) 10:42:21
>>775
同じじゃなくていいから、今私の手元にしかないハッシュ関数で同値をはじき出す
鍵を解読してください

777 :デフォルトの名無しさん:2006/09/17(日) 11:02:46
ともに16bitのハッシュ値を生成する場合、
「非公開のあなたのハッシュ関数」にランダムな入力を与えた場合に、偶然一致する確率は1/65536
「公開されている逆算不可能なハッシュ関数」にランダムな入力を与えた場合に、偶然一致する確率は1/65536
もちろん、逆算不可能というのが大前提だけどね。

778 :デフォルトの名無しさん:2006/09/17(日) 11:07:55
だから?

779 :デフォルトの名無しさん:2006/09/17(日) 11:08:10
>>776
馬鹿なの?

780 :デフォルトの名無しさん:2006/09/17(日) 11:09:50
>>ソースを隠せば解読が難しくなると思ってる奴がはびこってるあたり確かに低レベルだな
そもそもこの馬鹿にもの言ってるだけだからね

781 :デフォルトの名無しさん:2006/09/17(日) 11:12:20
>>775,777は当たり前のことをすごい知識かのように言ってるだけで

>>772-774の流れとはぜんぜん無関係で意味不明、意図がわからん
何が言いたいのだお前は?

782 :デフォルトの名無しさん:2006/09/17(日) 11:13:13
>>776
ソースはいらんから、その関数をどっかで実行できるようにしてくれ。

783 :デフォルトの名無しさん:2006/09/17(日) 11:14:22
>>782
サーバ間通信のログでいいかな?

784 :デフォルトの名無しさん:2006/09/17(日) 11:18:17
ああ、違うな普通ハッシュはサーバ上に保管するもんだしな
無理だなw
サーバでも盗むか?

785 :デフォルトの名無しさん:2006/09/17(日) 11:21:01
キーは素でDHで送っちゃうからな、見えないなw

786 :デフォルトの名無しさん:2006/09/17(日) 11:26:01
なにがなんだか

787 :デフォルトの名無しさん:2006/09/17(日) 11:51:35
ユーザIDは平文、パスワードは別の何かをくっつけたハッシュってのがベターなのでは

788 :デフォルトの名無しさん:2006/09/17(日) 12:43:13
気違いスレかよ

789 :デフォルトの名無しさん:2006/09/17(日) 13:31:25
>>788 もまえが一番外れているんだがな。

790 :デフォルトの名無しさん:2006/09/17(日) 13:46:34
だから夏休み終わっただろ?な?

791 :デフォルトの名無しさん:2006/09/17(日) 13:47:12
>>770
お前のことだよ>低レベル

792 :デフォルトの名無しさん:2006/09/17(日) 13:54:30
半年前から見てるけど、レベルの高かった事は少ないよ

793 :デフォルトの名無しさん:2006/09/17(日) 13:55:48
>>770
>>788-789
>>791
こいつらがスレ汚しか。
今年のお前らは、海にも行ってないだろ。

794 :デフォルトの名無しさん:2006/09/17(日) 16:11:01
16ビットハッシュなら6万5536通り全部試せば突破できるじゃん。
ジーオンデュアルなら1分も必要なくパスワード生成できると思う。

795 :デフォルトの名無しさん:2006/09/17(日) 16:28:14
生成式が解る場合の話だろ馬鹿

796 :デフォルトの名無しさん:2006/09/17(日) 16:30:16
実際アメリカの国防総省はSHA-1の改良型を使ってるんだが
お前の言ってることは、それもSHA-1と同じコストで算出できると言ってるわけだが
それならやってみろよw
ペンタゴンに動いてるものをくださいと言って見ろよw

797 :デフォルトの名無しさん:2006/09/17(日) 16:50:59
      r ‐、
      | ○ |         r‐‐、
     _,;ト - イ、      ∧l☆│∧  だが断る!
    (⌒`    ⌒・    ¨,、,,ト.-イ/,、 l  
    |ヽ  ~~⌒γ⌒) r'⌒ `!´ `⌒)  
   │ ヽー―'^ー-' ( ⌒γ⌒~~ /|  
   │  〉    |│  |`ー^ー― r' |
   │ /───| |  |/ |  l  ト、 |
   |  irー-、 ー ,} |    /     i
   | /   `X´ ヽ    /   入  |

798 :デフォルトの名無しさん:2006/09/17(日) 16:52:55
確かにペンタゴンだな。

799 :デフォルトの名無しさん:2006/09/17(日) 16:53:56
>>796
お前いい加減に2ch卒業しろよ

800 :デフォルトの名無しさん:2006/09/17(日) 17:36:39
おまえらまとめて、
ttp://pc8.2ch.net/test/read.cgi/tech/1088530204/
こっちいけ。


801 :デフォルトの名無しさん:2006/09/17(日) 18:49:39
ktwr

802 :デフォルトの名無しさん:2006/09/18(月) 00:00:09
winsock2.0にてrecv()のタイムアウトを以下のように設定しています。
int msec = 1;
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (char*)&msec, sizeof(msec));
1ミリ秒に設定してもrecv()が終了するまで500ミリ秒くらいかかるので
すが、そういうもんなんでしょうか?


803 :デフォルトの名無しさん:2006/09/18(月) 00:26:44
1ミリ秒のタイムアウトの意図がわからん
目的を言え

804 :デフォルトの名無しさん:2006/09/18(月) 00:28:24
スーパーコンピュータ?

805 :デフォルトの名無しさん:2006/09/18(月) 00:42:06
「目的を言え」などを最近よく目にするけど、
どういうつもりで目的を聞きたいのか、
その意図がなんか危ない人のようだ。

もしかしてそういう偉そうな事を言うのは、
オレの代わりに全部を引き受けてくれるのか?

806 :802:2006/09/18(月) 01:06:58
実際は30秒程度で使用することを考えてます。
一応どのくらいまで短くできるのか確認しておきたいのです。

807 :デフォルトの名無しさん:2006/09/18(月) 01:35:15
他のスレッドを殺して回ればもっと早く返ってくるぞ。

808 :デフォルトの名無しさん:2006/09/18(月) 08:18:21
>>802
きっちり調べずにカキコ。
Windowsのタイマーって、どこまでの精度だったっけ?
確か10msくらいじゃなかった?
あと、正確にタイマーの時間で返ってくるわけじゃないはず。
メッセージのキューの状態とか、CPUが忙しいとか、そういった要素で
変わってくるはず。
タイマーの値は「最低限その時間が過ぎた」ということを示すだけだったような。
推測ばっかりで、すまん。

809 :デフォルトの名無しさん:2006/09/18(月) 09:22:49
一応って言われてもねえ。サルじゃないんだから頭使おうよ。

recvが500msぐらいかかる
というのが分かっているんだったら、
timeoutも500ms程度の単位にしとけばいいんじゃないの?

それ以下、たとえば10msにするとして、
10ms単位で動かしたい別のタスクがあるの?
もしそうならループのつくりを変えたほうがいいと思う


810 :802:2006/09/19(火) 00:18:01
>>807
>>808
指定した時間で正確に返ってくるのではないんですねぇ。
タイマーを試してみましたが、SetTimer()も同様に正確ではありませんでした。
timeSetEvent()はかなり精度がよかったです。
>>809
話がとんでる気がしますが…。
1msと設定しても500ms程度かかるが、これが正しい動きであるかが知りたかったのです。
今回は30sを想定しているので特に問題はないです。
ありがとうございました。

811 :デフォルトの名無しさん:2006/09/20(水) 23:59:11
遅延のあるネットワークでの高速化手法をいろいろと検討しています。
そのなかで、WINDOWS XPにおけるOSで実装されたウィンドウサイズの機能と、
アプリケーション側からの制御のしくみがよくわかりません。

基本的にまずTCPの場合はウィンドウサイズの調整がスループットに効いてくると思います。
そこで様々な通信アプリの振る舞いをETHEREALで確認してみました。
XPの場合レジストリにウィンドウサイズの記述がありませんが、この場合64KBまで自動調整して
くれるようです。ただし、アプリケーション側によりウィンドウサイズパラメータ(正確にはSO_RCVBUF)を
いろいろと変化させてみても、WINDOWSが追従する範囲は16KB〜64KBまでの範囲です。
アプリで8KBに設定すると64KBでアドバタイズされます。レジストリでウィンドウズスケール
オプションを有効にすると、64KB以上に調整することは可能ですがアプリが側で64KB以下の設定をしても
反映されません。

MSのサイトには優先度の高い順として
1. 接続の SO_RCVBUF WinSock オプション。
2. インターフェイス別の TcpWindowSize レジストリ設定値
3.グローバル TcpWindowSize レジストリ設定値
4. NDIS により報告されたメディアのビット レートに基づく自動判定。 

のように記載されており、アプリの制御が最も優先度が高いはずなのですが思ったとおりに追従してくれません。
その理由について教えていただければ助かります。

いろいろなFTPソフトのやりとりをETHEREALで覗いてみると、TCPヘッダのウィンドウサイズのやりとりに
違いが無いにも関わらず(例えばクライアント32KB、サーバ64KB)、TCPMONでみたスループットの振る舞いが
大きくことなるものがあります。

根本的にウィンドウソケットバッファ(SO_RCVBUF)の制御は、直接TCPヘッダのウィンドウサイズに反映できる
と思っている私の考えはあっていますか?それとも、パケットキャプチャでは見えないメモリ上のやりとりを制御
しているのでしょうか?


812 :デフォルトの名無しさん:2006/09/21(木) 00:09:45
ソケット(セッション?)が有効であるか否かを
確認できる関数があると聞いたのですが、
それは何という関数ですか?
winsock2.h の recv(…) で取得したソケットが
まだ生きているのか否かを確認して、
死んでいたらスレッドを終了させるようなプログラムを
作りたいのですが・・・

813 :デフォルトの名無しさん:2006/09/21(木) 01:06:20
ルータがフラグメントしちゃったりパケット廃棄すれば遅くなるけどね。
遅延のあるネットワークは諦めるなり、遅延を受け入れて遅延しても問題無いようにアプリを作るしか無い。
遅延がある時点で、ル−タが懸命に遅延しても良いからバッファリングして流そうとがんばっていて負荷がかかってるのに、余計に負荷かけたらあっさりパケット廃棄されるだけ。

814 :デフォルトの名無しさん:2006/09/21(木) 01:36:00
>>812
セッションが終了してたらrecvにエラーが帰り益男

815 :デフォルトの名無しさん:2006/09/21(木) 07:01:19
>>811
MSDNのsetsockoptのSO_RCVBUFの説明にあるように、
SO_RCVBUFの値と、TCP Window Sizeは無関係。
Window sizeがどこまで上がるかってのは、レジストリで上限値を設定できる
だけで、あとはOS任せ。

816 :デフォルトの名無しさん:2006/09/21(木) 07:49:43
>>811
糞プログラマがTCP windowをコントロールすると、
(部分的でも)経路を共有している他の接続を圧迫するプログラムを書いて迷惑なので、

> 直接TCPヘッダのウィンドウサイズに反映できる

こういうことはできない。
どうしてもやりたければ、TCPのパケット(セグメント)を自分で作って送ること。
やりかたは、http://www.kt.rim.or.jp/~ksk/wskfaq-ja/advanced.html を熟読。
>>6あたりも。

817 :sage:2006/09/21(木) 15:23:36
javaのSocketクラスを用いてHTTP形式のデータをやり取りしているのですが
連続して実行しているとたまに

クライアント側:java.net.SocketException: Connection reset
サーバ側:ヘッダー箇所しか受信していなくデータ部を受信していない(受信データが欠落している)

というような現象が発生します。

クライアント<->サーバ間の問題??と思うのですが、
証拠がないのでしっくり来ません。

データが通信途中で欠落してしまう原因はなにかあるのでしょうか?

818 :デフォルトの名無しさん:2006/09/21(木) 15:24:31

orz

819 :デフォルトの名無しさん:2006/09/21(木) 18:17:17
サーバ側ってどうやってんの?
自前のJavaプログラムが単にlistenしてるだけ?
それともApache?

820 :デフォルトの名無しさん:2006/09/21(木) 20:11:19
>>817
JavaのSocketクラスを知らない俺がカキコ。
まったく見当違いのことを言っていたらすまん。先に謝っておく。

クライアント側がリセットされているんだから、サーバの動作を調べてみたら?
サーバ側がどんなやつなのかは分からないが、例えば、ヘッダーのデータが変だったから
データチェックエラーになって、コネクションをリセットしたとか。
サーバ側、クライアント側ともにメッセージは出力しないの?

あと「データが途中で欠落してしまう」は、どうなんだろうね。
その、ヘッダー箇所しか受信していないっていうのは、どうやって判断したの?
上にも書いたけど、単に1回recvして(その時点で全データの途中まで受信して)、
ヘッダーのデータが変だったから、そこで処理終了なんて場合はないんだろうか。
その場合とかだと、データが途中で欠落しているのではないわけで。

821 :820:2006/09/21(木) 20:15:13
あ〜、連続して実行しているときか。
なんか、サーバ側でコネクションをリセットするケースを調べたほうが
早いような気がしてきた。
連続カキコ、すまん。

822 :デフォルトの名無しさん:2006/09/21(木) 22:49:35
HTTP/1.1のKeepAlive使ってて、
・クライアントがPOSTするデータのサイズに嘘ついてる
・サーバがPOSTされたデータのサイズの解釈を誤っている
とか

HTTP なら Ethereal でモニタしてみれば原因はすぐわかると思うが。

823 :811:2006/09/22(金) 01:22:10
>>815,816

情報ありがとうございます。本日もいろいろと調べたところ
SO_RCVBUF does not necessarilly correspond to the size of TCP receive window
なる文書をMSDNで見つけました。
ということで、以下のように無理やり理解したのですが誤っていればご指摘ください。

ソケット処理なのでTCP処理の直後に位置することから、OSが制御するTCP処理を
直接制御することはできない。TCP受信ソケットバッファ(SO_RCVBUF)とは、OSが用意
するウィンドウサイズバッファに含まれるデータをアプリケーションに引き渡すプロセス
で利用する中間バッファである。よって、OSのウィンドウサイズ調整が適切なものに
なっていると仮定すれば、OSのウィンドウサイズバッファとTCP受信ソケットバッファは
同じ値を利用したほうが良い。もし、SO_RCVBUFを無理やりOSがアドバタイズする
TCPウィンドウサイズより小さい値にすると、場合によってはTCP層からソケット層への
データの受け渡しが非効率的となりスループットが落ちる。また、これらはソケット層の
振る舞いであるため、ETHEREAL等のパケットキャプチャでは状況を確認できない。

上記が正しいならば、高速高遅延のIP回線に対する処置はまずOSでWINDOWスケール
オプションを有効にした上で、それに見合うソケットバッファを用意すればよい。と・・・・。

どうでしょうか?

824 :816:2006/09/22(金) 09:25:30
まあそれでいいんだけど、
高速高遅延回線でのTCPのwindowサイズコントロールアルゴリズムを
詳しく知りたい時は、
http://en.wikipedia.org/wiki/Van_Jacobson
さんたちの書いた論文でも読んでください。

ある程度データを送らないとwindowsサイズが大きくならないので、
少ししかデータを送らない場合には、UDPを検討してください。
ただ手前勝手な転送を行うと軋轢が起きて、
結局自分のパケットも失われるし、スループットの安定性もなくなる。


825 :デフォルトの名無しさん:2006/09/22(金) 09:30:38
>>819
レスありがとうございます。

サーバ側もjavaで組んでます。
なんでなんちゃってHTTPって感じです。

826 :デフォルトの名無しさん:2006/09/22(金) 09:36:27
>>820

ヘッダー箇所は
全て固定で入れていて
基本的には動いていまして
間違っていないかと思うんですよ。。。

終了判断は
\0検出か、
タイムアウトか、
受信データがなし(InputStream.read()==-1)
で判断してます。

827 :デフォルトの名無しさん:2006/09/22(金) 09:37:40
>>821

サーバ側で故意にリセットしてるんですかねぇ。
調べてみます。
レスサンクスです。

828 :デフォルトの名無しさん:2006/09/22(金) 09:45:18
>>822

Content_lengthは成功してるときも失敗してる時も
同じ値を示してて問題ないかと思います。
データ部も全く同じで。

それにjavaで作成したサーバなんで
基本的にヘッダとか意識もしないはずなんです。

まったくわからんす。。。orz

今日パケット収集してみます。

ありがとうです。

「HTTP/1.1のKeepAlive」
初ワードなんで調べてみます。

829 :デフォルトの名無しさん:2006/09/22(金) 10:45:41
問題だなと思うところのコードをさらした方が解決は早いよ。
きっと自分の思い違いだと思うからさ。

830 :デフォルトの名無しさん:2006/09/22(金) 11:12:05
相手を本物のHTTPのサーバ/クライアントに、
入れ替えて試してみろよ、respectively。

831 :デフォルトの名無しさん:2006/09/22(金) 12:33:03
>>828
一応、HTTP/1.1に"keep-alive"は無いよ。
keep-aliveは1.0の拡張で、不完全だから1.1で改善したんだし
1.1なら何も指定しなければその上位動作のpersistent connection

832 :デフォルトの名無しさん:2006/09/22(金) 13:54:41
HTTP以前の問題な希ガス

833 :デフォルトの名無しさん:2006/09/22(金) 14:08:19
んー、2chなんかでも、多数のセッション張る(各鯖毎1本にしてるよ)と
たまに原因不明のECONNRESET入るから、なんともいえないね。
原因がサーバー側(OS,apache)なのか、経路(特に家庭用ルータ)なのか
それともクライアントOSやアプリなのかも全然わかんないし。
それが起きたときの鯖側の忙しさとかも調べようが無いし
再現性もないしね。

834 :デフォルトの名無しさん:2006/09/22(金) 14:19:21
その立場は曖昧すぎるかと。

少なくとも>>817はクライアント・サーバの双方を作っているので、
自分のプログラムに原因がないかどうかを調べようとしている。

ECONNRESETだと、ICMPとか、RSTフラグとか、あやすい



835 :デフォルトの名無しさん:2006/09/22(金) 15:24:47
大量に接続・切断すると
ローカルでもおかしくなるよ

836 :デフォルトの名無しさん:2006/09/22(金) 16:45:28
ならんがな。

837 :デフォルトの名無しさん:2006/09/23(土) 08:11:44
しらんがな。

838 :デフォルトの名無しさん:2006/09/25(月) 17:29:09
お前らwinsockで192.168...の自分のPCのアドレスってどうやって取得するか教えて下さい

839 :デフォルトの名無しさん:2006/09/25(月) 18:19:42
localhost

840 :デフォルトの名無しさん:2006/09/25(月) 18:38:43
>>839
127.0.0.1

>>838
IpHelperなら、GetAdaptersAddressesでとれると思うけど、
winsockで、となると知らん。

841 :デフォルトの名無しさん:2006/09/25(月) 19:36:01
ネットワークはちょっとしかかじったことないから
localhostで自分のアドレス取得できると思ってたorz

>>839
winsock gethostbynameでぐぐってみ

842 :デフォルトの名無しさん:2006/09/25(月) 21:02:28
>>841
Niceなボケだと思ってたがマジレスだったんか。orz

843 :デフォルトの名無しさん:2006/09/26(火) 06:54:23
linuxでipconfigを使って一つのnicに複数のipを割り当てることが可能なんですが
Windowsでこれと同じことって出来ますかね
出来ればプログラムでやりたいですが

844 :デフォルトの名無しさん:2006/09/26(火) 07:13:46
http://www.ntkernel.com/w&p.php?id=32

845 :デフォルトの名無しさん:2006/09/26(火) 11:09:46
>>843
TCP/IPのプロパティから追加できる。
プログラムで、となると、AddIPAddressか。動くか知りませんが。

>>844
それは、仮想アダプタ (仮想NIC)

846 :デフォルトの名無しさん:2006/09/27(水) 19:19:27
C++Builder(1997年版)をWin95にインストールしてたんだけど
C++が書けなくて行き詰っていた。
C++言語をマスターしたし、TCPIPもソケット関数の使い方が
判りますた。
このC++BuilderでTCP/IP通信プログラムは組めるでしょうか?

BorlandC++4.0ももってますがこれはネットワーク通信に対応してません。
最新のBorlandC++5.5はFreeのコマンドラインツールになりましたが、
こちらは関数マニュアルが無く、TCPIP通信は無理です。

847 :デフォルトの名無しさん:2006/09/27(水) 19:21:34
>>846
補足:
現在は、SUN OS上で、CUIのソケット通信をプログラムできるようになりました。
VC++は経験、使用ライセンスもありません。


848 :デフォルトの名無しさん:2006/09/27(水) 19:32:33
platform SDKがついていればできそうな気がする。
インストールしてsocket() とかsendto()とかヘルプで引いてみればいいんでないの?

849 :デフォルトの名無しさん:2006/09/27(水) 19:34:53
ふつうに新しいVCをダウンロードしてインストールすればいいじゃないか

850 :デフォルトの名無しさん:2006/09/27(水) 21:37:51
HTTPクライアントでメソッド(とヘッダ)の行終了を示す改行を送信するとき、
\n でやっても \r\n でやってもHTTPサーバーは正常にレスを返します。
これは\nであれば、弾いてエラーを返すべきじゃないですか?

851 :デフォルトの名無しさん:2006/09/27(水) 21:51:26
すれば?

852 :(^-^) ◆MONSOON/qo :2006/09/27(水) 22:06:15
>>850
UNIXの改行 \r\n
Windowsの改行 \n
だから
どちらも認識した方が便利ではある

853 :デフォルトの名無しさん:2006/09/27(水) 22:12:38
RFC ?

854 :デフォルトの名無しさん:2006/09/27(水) 22:34:23
See rfc791.
>一般的に実装は、送信側の動作では堅実でなければならず、受信側の
>動作では寛容でなければならない。つまり、注意して適切な形のデータグラムを送信しなければな
>らないが、解釈可能なデータグラムは全て受け入れなければならない(例えば、技術的には誤りで
>あっても意図が明らかであれば黙認する)。

855 :デフォルトの名無しさん:2006/09/27(水) 22:42:17
>>854
あまり文句は言いたくないが、終焉コード(記号)は
寛大じゃダメだろ。それなら、\r\n \r \nの3つを終焉と定義しとけ!

856 :デフォルトの名無しさん:2006/09/27(水) 22:43:04
一応rfcでは\r\nになってますな

857 :デフォルトの名無しさん:2006/09/27(水) 22:45:44
そうやって寛大だから、HTTP/1.1のサーバーを名乗ちゃうんだよな〜

858 :デフォルトの名無しさん:2006/09/27(水) 23:28:07
Win95は再インスコでC++Builder入れなおしだから
インスコしてhelp見ます。
もし経験あるかたあったらTCPソケット使えるか
おせーてくらさい。
VCは高杉で無理です。

859 :デフォルトの名無しさん:2006/09/27(水) 23:43:33
無料のVCすら使えないとは乞食もびっくりだ

860 :デフォルトの名無しさん:2006/09/27(水) 23:49:01
>>858
どの環境でもソケット使える
BSDソケットな部分なら、ネット上にサンプルもたくさん転がってる
がんばれ

861 :デフォルトの名無しさん:2006/09/27(水) 23:49:29
さすがにWin95じゃVC.NETは使えないな。
ネットに繋いだらウイルスばら撒きPCにしかならないだろうし。

862 :デフォルトの名無しさん:2006/09/28(木) 00:34:58
でんでんむし!

863 :デフォルトの名無しさん:2006/09/28(木) 06:20:06
>>858
生のWinsockも使えるし、TClientSocketとかを使うことも出来るけど?

>>850
RFCで、CRLFの組を、CRを無視してLFのみとして扱うこと奨めて(SHOULDではない)いる。
もちろん、本来CRLFがあるべきところにLFのみが送られても、動くようにするため。
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec19.3
だから、サーバーがそういう動作をするのは、別に規格外というわけではなし、
エラーを返さなくても何ら問題はない。

864 :デフォルトの名無しさん:2006/09/28(木) 09:58:03
rfcのshouldとmustの違いは重要。
日本語訳だけ見てると実装の解釈を間違えるかもな。

865 :デフォルトの名無しさん:2006/09/28(木) 11:01:16
推奨するといいつつも、規格書なのに処理方法が書いてあるんじゃないか?
べつに意義は無いけど。

866 :817:2006/09/28(木) 11:41:00
亀レスでスマンす。
原因わかったんで報告をば。

パケットを解析したら
ヘッダ部とボディー部が違うパケットで飛んでました。
んで色々解析した結果

socket = serverSocket.accept();

│ヘッダー部のみ受信

socket.getInputStream().read(1024);
⇒ヘッダー部しか受信しない

socket = serverSocket.accept();

│ヘッダー部、ボディー部を受信

socket.getInputStream().read(1024);
⇒OK

って感じでした。

867 :817:2006/09/28(木) 11:41:54
アセプトで接続確立してから
リードで受信読み取りするまでの間で
ヘッダー部とボディー部受信してたらOKだけど
ヘッダー部のみしかまだ受信できてない場合は
ヘッダー部のみしか受信読み取りしなかったみたいです。

けどこれってどうやって解決???

なんかJavaのどのクラス使っても終端コードが読めなくって
無限ループ使用して終端コードで抜けるみたいにすると
無限ループはしないんですけど処理が止まってしまうんですよ。。。
(ログ出力すると「^@」や「・」みたいのがわんさか最後にくっついてる)
なんで今は1024バイト決めうちで取ってるんですけど。。。

そうしたらこの問題でるし。。。

JavaでHTTPサーバこしらえる限界なのかなぁ。
javaライクな話でゴメンす。
なにはともあれサンクスですっ。

868 :デフォルトの名無しさん:2006/09/28(木) 12:14:18
>>867
> JavaでHTTPサーバこしらえる限界なのかなぁ。

おまえの限界ですから。


869 :デフォルトの名無しさん:2006/09/28(木) 13:18:19
>>868
BufferedReader
InputStream
で試したんですけど全然とれなかったんですよ。

後Socketのデータ読めるクラスって知ってます?

助言ください。m(_ _)m

870 :デフォルトの名無しさん:2006/09/28(木) 13:33:40
>>869
もしかしてストリームが分かってない…?

871 :デフォルトの名無しさん:2006/09/28(木) 13:53:36
落ちこぼれの一番ダメなパターンだな。

872 :デフォルトの名無しさん:2006/09/28(木) 14:59:45
>>870
そういわれたら説明できん。。。orz

873 :デフォルトの名無しさん:2006/09/28(木) 15:01:08
>>871
でたとこ勝負てきな感じでやってきたんで
きちんとした知識ないかも。。。

知識くれ。

874 :デフォルトの名無しさん:2006/09/28(木) 15:03:16
とりあえず

//InputStream
//read()
⇒処理が「^@」や「・」位置にくると止まる
//read(byte[])
⇒正常だがバイト分は取れるが「^@」や「・」のも取れてしまう
//read(byte[], int, int)
⇒正常だがバイト分は取れるが「^@」や「・」のも取れてしまう

875 :デフォルトの名無しさん:2006/09/28(木) 15:04:16
//InputStreamReader
//read()
⇒処理が「^@」や「・」位置にくると止まる
//read()+ready()
⇒正常
//read(char[], int, int)
⇒正常だがバイト分は取れるが「^@」や「・」のも取れてしまう

876 :デフォルトの名無しさん:2006/09/28(木) 15:05:12
//BufferedReader
//read()
⇒処理が「^@」や「・」位置にくると止まる
//read()+ready()
⇒正常
//read(char[], int, int)
⇒正常だがバイト分は取れるが「^@」や「・」のも取れてしまう
//readLine()
⇒処理が「^@」や「・」位置にくると止まる
//readLine()+ready();
⇒処理が「^@」や「・」位置にくると止まる

試しました。

877 :デフォルトの名無しさん:2006/09/28(木) 15:14:27
チラシは分かったけど、だから?

878 :デフォルトの名無しさん:2006/09/28(木) 15:26:38
おいこれねっとわーくとなんかかんけいがあんのか

879 :デフォルトの名無しさん:2006/09/28(木) 18:16:08
この(^-^) ◆MONSOON/qoってやつ何者?
ヘンな知識ひけらかすなよ

880 :デフォルトの名無しさん:2006/09/28(木) 18:31:29
>>879
無視しろ

881 :デフォルトの名無しさん:2006/09/28(木) 18:40:49
>>874-876
HTTPのストリームを*Readerで読む意図が分からん。
途中でエンコーディング切り替わるぞ。

>//read(byte[])
>⇒正常だがバイト分は取れるが「^@」や「・」のも取れてしまう
read(byte[])の戻り値をきちんと調べること。

つーか、javaはjavaでやれ。
ttp://pc8.2ch.net/test/read.cgi/tech/1086238859/

882 :デフォルトの名無しさん:2006/09/28(木) 18:43:03
>>879
>>852
>UNIXの改行 \r\n
>Windowsの改行 \n

確かにヘンな知識だな。

883 :デフォルトの名無しさん:2006/09/28(木) 19:04:27
35 名前: (^-^) ◆MONSOON/qo 投稿日: 2006/09/27(水) 22:03:51
テンプレートとかクラスとか使ったことないんだけどやばい?
普通に配列にアクセスしていく方がやりやすいんだけど
多数で開発とかじゃないといらなくない?

C++相談室での発言。
おどろいた。

884 :デフォルトの名無しさん:2006/09/28(木) 19:10:33
無視しろ

885 :デフォルトの名無しさん:2006/09/28(木) 19:19:35
クラスは余計複雑にする場合もあるが、テンプレート利点しかない

886 :デフォルトの名無しさん:2006/09/28(木) 19:54:08
ネタでしょ

887 :デフォルトの名無しさん:2006/09/28(木) 19:58:35
特定個人に何か言いたいことがあるなら、直接そのスレで言え

888 :デフォルトの名無しさん:2006/09/29(金) 03:10:18
自分は人を見下すのは好きだけど、論理展開力が無くて返り討ち必至だから
直接対決なんてこわくて出来ません(>_<)

889 :デフォルトの名無しさん:2006/09/29(金) 05:18:42
>>854
RFCの古さに注目。
いまどきは悪意を持って壊れたデータを送ってくるクライアントの存在を前提に
厳格な解釈をすることも多い。
詳細はHTTP Request SmugglingtとかHTTP Response Splittingでぐぐってみて

890 :デフォルトの名無しさん:2006/09/29(金) 05:19:20
Smugglingt
なんか変なゴミが。Smugglingね。

891 :デフォルトの名無しさん:2006/09/29(金) 10:32:18
>>889
確かに古いRFCだけど、言ってる内容は有名な格言で、
Postel's Law とか Robustness Principle と呼ばれるやつだよ

  Be liveral in what you accept, and conservative in what you send.

当然悪意のある入力に対して壊れたりセキュリティホールが空いてたりするのは駄目だけど、
この原則はこれでまた大いに意味がある
要はバランス感覚ってところじゃないかしら


892 :デフォルトの名無しさん:2006/09/29(金) 10:52:23
RFC書いた奴が馬鹿なんだよ


893 :デフォルトの名無しさん:2006/09/29(金) 10:55:02
読んでそれをバカと言ってるヤツがバカじゃない可能性のほうが低い

894 :デフォルトの名無しさん:2006/09/29(金) 13:46:24
>>893 おまえがバカってことはよく分かった。

895 :デフォルトの名無しさん:2006/09/29(金) 13:47:58
俺も俺も。

896 :デフォルトの名無しさん:2006/09/29(金) 14:06:35
なんで改行コードは0x0d 0x0aなんだろうね。
2バイトもあって無駄じゃんwww

897 :デフォルトの名無しさん:2006/09/29(金) 14:11:58
0x0dはCRで0x0aはLFだから。

898 :デフォルトの名無しさん:2006/09/29(金) 14:56:29
>>896
CP/Mのせいかな。

899 :デフォルトの名無しさん:2006/09/29(金) 15:13:16
ラインプリンターなんかだと CR で左に逃げて LF で紙送りしてたから
プリンター/ディスプレイ/ファイル内 で 改行コードが同一になる CRLF はありがたかった

900 :デフォルトの名無しさん:2006/09/29(金) 15:52:15
>>889
HTTPについてのRFCは2616が最新なんだけど
>>863も読んだ上で言ってるんだよね?

901 :デフォルトの名無しさん:2006/09/29(金) 16:17:29
RFCは文書の古さより置き換える新しい文書があるかどうか。

902 :デフォルトの名無しさん:2006/09/29(金) 21:43:03
もっと新しいRFC 1958にも
> Be strict when sending and tolerant when receiving.
と書かれてる。つーかこっちのほうが有名じゃまいか

4000番台のRFCでこれに反論したものもあったはずだけど番号が分からない

903 :デフォルトの名無しさん:2006/09/29(金) 22:58:58
柔軟に処理してあげるのが普通になると、
規格に厳密に振舞うことの価値が下がってしまう
規格の存在意義の消失→オレオレ仕様が跋扈する時代へ
それでもいいの?

とかそういう話かねえ。

904 :デフォルトの名無しさん:2006/09/29(金) 23:08:35
>>903
そうそう。確か規格違反のクライアントの誤りが修正される機会が失われて、
最終的に相互運用性が失われてしまうとかそんな感じの内容だった

905 :デフォルトの名無しさん:2006/09/29(金) 23:10:55
それでいいんだけど、それをまとめるなきゃいけないときが
一番辛いんだよね…

906 :デフォルトの名無しさん:2006/09/29(金) 23:32:23
違反してる奴が悪いだろ

907 :デフォルトの名無しさん:2006/09/30(土) 12:15:34
でも違反してる香具師がデファクトスタンダードになると対応させられることが多いのも事実。
IE規格のHTMLとかさ。

改行コードは昔は出力装置にプリンタしかなかった頃の名残を未だに引きずってる。
行表示のディスプレイから始まって、スクリーン表示に成ってグラフィック端末になったし。
詳しくは歴史の勉強でもしてくれ。

908 :デフォルトの名無しさん:2006/09/30(土) 16:55:21
>>860 >>863
昨日、TCP/IPプログラムの処女作になるTCP/IP印刷ユーティリティを
作りました。
SUN OS用に3時間かかったけど、
Windows版(Bcc++5.5使用)は2時間で完成しました。

GUIはツールが無く、使い方も知らないのですが、
VC++の180日評価版は、個人での購入は可能でしょうか。
6が月あれば相当マンセーできると期待してるんですが。


909 :(^-^) ◆MONSOON/qo :2006/09/30(土) 17:08:33
>>908
マイクロソフトのvisual stdio 2005(vb c++ c# java) express edtionは
無料配布されてますよ

http://www.microsoft.com/japan/msdn/vstudio/

910 :デフォルトの名無しさん:2006/09/30(土) 17:59:38
>>909
OSがWin95の奴にそれをすすめるんか?
アホちゃうか

911 :デフォルトの名無しさん:2006/09/30(土) 18:10:52
>>909
そしてまた嘘言うな
javaは含まれてねーですよ

>>910
つ 一応VC7行こうでもネイティブを吐けるので、もしかしたら吐き出したEXE動くかもしれない
が、開発環境は無理だな
そして質問は開発環境っぽいので>>910が真

912 :デフォルトの名無しさん:2006/09/30(土) 18:39:52
VC8のEXEはWin95で動かんよ。

913 :デフォルトの名無しさん:2006/09/30(土) 18:45:33
>>912
みたいだね

VC8のランタイムはWin98移行かららすぃds
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&DisplayLang=ja

914 :デフォルトの名無しさん:2006/09/30(土) 18:51:10
ネットワークプログラミング固有の話でもないんですが質問です。
今とあるプロトコルを作ってるのですが、
NAME1
NAME2
NAME3
と任意の数の任意の文字列を伝える場合、
どういう形式で送るのが好ましいでしょうか?
最初は、 ,や#や~で区切る方向だったんですが、それだと文字列にそれらの文字が使えなくなりますし・・・
それにこの文字列には改行コードが含まれる事もあるので、それも使えません。

コマンドの先頭にオフセットを付加する事も検討しているのですが、一般的にはこういうのはどういう手段で解決しているのでしょうか?


915 :デフォルトの名無しさん:2006/09/30(土) 18:53:43
>>914
Cだって\を表示したいときは\\だろ?

916 :デフォルトの名無しさん:2006/09/30(土) 18:55:49
・hex dump
・string length
・escape sequence (SMTPの.行など)
・XML
・BER




917 :デフォルトの名無しさん:2006/09/30(土) 18:56:07
>>914
とりあえずHTTPでのヘッダやフィールドなんかはまんま送ってるよな
あれは内部で特殊文字をエスケープしたりしてるはず
というわけで、
> 最初は、 ,や#や~で区切る方向だったんですが、それだと文字列にそれらの文字が使えなくなりますし・・・
> それにこの文字列には改行コードが含まれる事もあるので、それも使えません。
は送れるし、改行コードだって使える
表記と意味をもう少し考えよう

もう一つは「送るサイズ」とデータをまとめて送る方法だが、
まぁその”サイズ”とやらをどうやって表現するかとか、送るサイズは決まってないけどとりあえず送りたいときなんかは
無駄な表現になるかもしれない

とりあえず時と場合による

918 :デフォルトの名無しさん:2006/09/30(土) 18:58:01
>>915
> \を表示したいときは
< \をデータに含めたいときは


919 :デフォルトの名無しさん:2006/09/30(土) 19:03:36
>>918
文字列リテラルの中だけの話でしょ?

920 :デフォルトの名無しさん:2006/09/30(土) 19:17:59
文字リテラル('\\')もそう。

ちなみに、printfは、\\を見て\を出力ということはやってない。
%と\を混同している人が多いが。printfの書式指定は%。
改行処理は書式文字列に埋め込まれた改行コードを出力しているだけ。

921 :デフォルトの名無しさん:2006/09/30(土) 19:40:26

ちと誤解があるようなので。
OSはWin95も使ってますが、
MS-DOS6.2、7.0,Windows3.1,Wi95、Win98SE、
Win2000、WinXP Pro, SunOS、ソラリス
以上を現用です。
昔は、H8350、VAX11、MDS(86)、CBM-3032なんてのも
マンセーしました。


922 :デフォルトの名無しさん:2006/09/30(土) 20:08:46
それだけ使った事あって、ネットワークのプログラムを作った事ないなんて、なにが楽しかったの?

923 :デフォルトの名無しさん:2006/09/30(土) 20:15:18
ちょっと使うためとかで自作プロトコルを作るときって、
バッファとかでガバッてやると、終了とかサイズとかの処理が面倒だし
やっぱり1バイトづつ(とか先読みとか)読み取って処理するのが一番楽だよね?

924 :デフォルトの名無しさん:2006/09/30(土) 20:16:40
>>911
909はJ#とJavaの区別が付いてないんだな

925 :デフォルトの名無しさん:2006/09/30(土) 20:17:47
>>923
そこまで決めちゃうプロトコルなの?
実装の話は抜かして進めないと先がどんどん見えなくなっていくよ

926 :デフォルトの名無しさん:2006/09/30(土) 20:29:34
>>925
やるなら、1バイト(もしくは数バイト)ごとがいいとか、
そういう話じゃないのか?

927 :デフォルトの名無しさん:2006/09/30(土) 20:33:28
>>923
TLVのマーシャリング、アンマーシャリングを行う汎用クラスを作っといて、
I/Oはそいつに任せる。
個別のプログラムは、TLVの意味解釈のみ。

928 :デフォルトの名無しさん:2006/09/30(土) 20:50:37
>>927それだと結局は既存の使ったほうが楽じゃないか?

929 :デフォルトの名無しさん:2006/09/30(土) 20:53:53
>>928
新しいプロトコル作るまでは話が進んでいるんだから、
そっちに後戻りするのはちょっと受け入れられない条件なんじゃまいか?
(最悪"TCPがあるじゃん!"に落ち着いてHTTPもSMTPもTCPに含まれちゃうことになっちゃうぞ)

とりあえず俺も今シコシコやってるから反論してみた、反省はしていない

930 :デフォルトの名無しさん:2006/09/30(土) 21:00:14
滑らかにバッファのカーソルをずらす上手い方法ないかな?
あるプロトコルの命令句を取り出したら、余ったバッファの値を
バッファの先頭に持って行きたいんだよね。

同じサイズのバッファを沢山プールして、フリーのバッファにmemcpyとかしかない?

931 :デフォルトの名無しさん:2006/09/30(土) 21:14:58

今の学生さんは普通にインターネット使って
普通にパソコンのキーを叩いてますし、
ネットワークプログラミングもナラってます。
たわしが学生時代は大型計算機全盛で、
MSもMS-DOSも影も形もなく
ネットワークはおろかパソコン通信もなかったんですわ。



932 :デフォルトの名無しさん:2006/09/30(土) 21:21:36
>>931
何がいいたいの?

933 :デフォルトの名無しさん:2006/09/30(土) 21:26:41
1980年代前半にはMSはもうバリバリだったし、MS-DOSも発売されてた。
一体何歳の人?

934 :デフォルトの名無しさん:2006/09/30(土) 21:29:42
結局1バイトずつが楽なんじゃないか!
何でそんなにバッファとか面倒なことにこだわるんだ?

特に>>929 >>930に言いたい!

935 :デフォルトの名無しさん:2006/09/30(土) 21:35:42
負荷を軽くするためだろ

936 :デフォルトの名無しさん:2006/09/30(土) 21:47:40
>>934
そんなこといわれてもなー
プロトコルにかんけいないしー

937 :デフォルトの名無しさん:2006/09/30(土) 22:03:17
プロトコルに関係ある話って具体的には何?

938 :デフォルトの名無しさん:2006/09/30(土) 22:04:16
1)1バイトずつ読んで解釈する部分と、
2)まとめて読み込んで1)に1バイトずつ返す部分、
の2つに分ければよろし。

939 :デフォルトの名無しさん:2006/09/30(土) 22:15:16
だよね。

940 :デフォルトの名無しさん:2006/09/30(土) 22:30:37
>>933
最初のMS-DOSはNECのPC-100で使った。
会社だから買えたけど100万円もしたんじゃ
とても個人じゃMS-DOS機は買えんかった。
DOS無しでも研究のオリジナル8086オリジナル機
で画像認識処理を研究しとったよ。
メインフレームと連携させてよ。
VAXマシンやTSSはケーブルでは
多数つながっていたが、LANではなくて
チャネルという呼び方をしてた。
当時はOSIレイヤが7層構造で・・・
みたいなお堅い空論だけが論文に
出てたが実験段階で製品レベルでは
なかった。


941 :デフォルトの名無しさん:2006/09/30(土) 22:38:40
>>940
時代考証間違ってないか?
ボケた?

942 :デフォルトの名無しさん:2006/09/30(土) 22:43:26
>>940
この人の歴史がそのまま計算機の歴史なのか…
HPとかブログで思い出話つづってくれると、とってもいいかも。
博物館とかで昔の人の知恵を見るの好きなので・…

943 :デフォルトの名無しさん:2006/09/30(土) 22:45:56
>>940
だから、何歳なんだよ?

944 :デフォルトの名無しさん:2006/09/30(土) 22:47:07
>>930
リングバッファじゃ駄目なのか?

945 :デフォルトの名無しさん:2006/09/30(土) 23:01:37
>>942
まあ今でこそネットワーク花盛りだけど
いろいろみんなの努力があって現在があると思ってますよ。
主にハード制御と基板設計だったけど、
今ではハックされないSSLプログラミング実装と
FPGAのVHDLでも頑張ってるよ。


946 :デフォルトの名無しさん:2006/09/30(土) 23:02:22
何なのこの人

947 :デフォルトの名無しさん:2006/09/30(土) 23:03:32
>>946
ソフトとハードいぢってる人なんじゃね?

948 :デフォルトの名無しさん:2006/09/30(土) 23:05:39
うざ

949 :デフォルトの名無しさん:2006/09/30(土) 23:27:05
久々の休みで、くつろいでるんだけど?
無知で若くていいなってね。

950 :デフォルトの名無しさん:2006/09/30(土) 23:30:51
今だ現役で、現場でバリバリで、こんなスレまでチェックして、
年取っていても、おまえらよりも好奇心は数倍上なんじゃ!

お前ら、頭下げんか!!

951 :デフォルトの名無しさん:2006/09/30(土) 23:33:30
既に壮年と呼ばれる年齢に達して、一部ハゲてる俺がきましたよ
とりあえず>>949は俺に頭下げろ

952 :デフォルトの名無しさん:2006/09/30(土) 23:36:09
俺60歳だけど。
みんな俺に平伏せ。

953 :デフォルトの名無しさん:2006/09/30(土) 23:39:50
年功序列って言葉も昔はあったよね。
何もかもが懐かしい。俺25。

954 :デフォルトの名無しさん:2006/09/30(土) 23:43:13
制御にいく、ソフト(今だとWeb)に行くか迷うよな。

955 :デフォルトの名無しさん:2006/10/01(日) 00:12:14
プログラマ板行けよ

956 :デフォルトの名無しさん:2006/10/01(日) 02:40:29
ソケットをcloseした直後に、そこ宛に届いたパケットって、どうなるの?
ソケットバッファはcloseした際にfreeされるんだろうけど、そのもっと下のレイヤーの
中の人達は、そのパケットをどう処理するの? 

957 :デフォルトの名無しさん:2006/10/01(日) 02:47:11
>>956
Socketライブラリの話をしてるなら
その前にshutdown()があるだろ?
そっちを参照しれ

958 :デフォルトの名無しさん:2006/10/01(日) 02:50:44
>>956
FAQ読め。half closedとか。

959 :デフォルトの名無しさん:2006/10/01(日) 03:51:35
>>914
遅レスだが
,で区切るなら
まず全ての,に,を追加する
つまり,や,,,は、,,とか,,,,,とかになるわけ。
あとは,でマッチするヤツで分離
処理後は,を1つ減らす。

960 :デフォルトの名無しさん:2006/10/01(日) 04:19:45
多分それだと、
,
,
,
な項目が出た時に判別方法ナスw
まぁ、n/2出来るかどうかで後からつけたかどうかは判別できるかな
スマートな方法ではないが・・・。



961 :デフォルトの名無しさん:2006/10/01(日) 07:02:45
>>959
以下で、空白区切りレコードデータは、
test1 test2
,区切りレコードでは、
test1,test2
と表現するとしよう。

空白区切りレコードデータ、
test1, test2

test1 ,test2
も、,区切りレコード&あなたのエスケープの方法では、
test1,,,test2
となって区別がつかない。

メタ記号とは、別の記号でエスケープするのが基本である。

この話題はネットワークに直接関係ないし、
レベルも低いので、くだ質に移ることにしないか?
SOCK_SEQPACKETや上位フレームワークを使うのでない限り。


962 :デフォルトの名無しさん:2006/10/01(日) 07:24:16
レベル低い話は無視すれば淘汰されるだろ
相手するから続く

963 :デフォルトの名無しさん:2006/10/01(日) 07:31:56
いつも思うんだが、ここで出てくるレベル低いってワード
そもそも、ネットワークプログラミングに関することでレベルの高い話題って出た事ある?w

964 :デフォルトの名無しさん:2006/10/01(日) 07:39:45
>>963
ないなw
バッファのサイズやら、ブロッキングしない方法やらCRLFやら・・・
自分の力量に影響される部分ではなく、ごくごく基本となる話題ばっかだ。HelloWorldで言えばprintf()関数の使い方を聞いてるようなもん
誰がやっても同じになる部分だけに、ヘルプ読めで終わる。
どう考えてもプロトコルの設計の話の方がプログラマの創造する部分なだけ、レベルはワンランク高い。

どっちもドングリの背比べだが・・・


965 :デフォルトの名無しさん:2006/10/01(日) 09:20:16
大抵のネットワークプログラミングにおいて、「ネットワーク」の部分は
単に「決まり事を理解してる・してない」の問題で、
それを含んだ「難しい箇所」の話もう別のスレの領分になっちゃうからな。

966 :デフォルトの名無しさん:2006/10/01(日) 09:47:22
rfc読めるか読めないかで勝敗は決まってる。
向いてないならネットプログラミングは避けるのが無難。

あとプログラマでちょっとプログラム書けば確かめられるのに、手を動かさずにまず訊くのは何なの?
正解を求める廚ですか?

967 :デフォルトの名無しさん:2006/10/01(日) 09:51:03
動けば良いってわけじゃないでしょ。
もしかすると、たまたま動いたってだけかもしれない。
そんな危険なコード世に出せる神経が理解できない。

968 :デフォルトの名無しさん:2006/10/01(日) 11:33:17
>>965-967

969 :デフォルトの名無しさん:2006/10/01(日) 13:08:33
いつも思うんだが、お前らの言うレベルの高いお話ってどんなお話?

970 :デフォルトの名無しさん:2006/10/01(日) 13:11:04
レベルが低くないお話のことだよ

971 :デフォルトの名無しさん:2006/10/01(日) 13:16:05
いつも思うんだが、お前らの言うレベルが低くないお話ってどんなお話?

972 :デフォルトの名無しさん:2006/10/01(日) 13:20:36
俺らは集団の個人であってまとままってるわけじゃないし
なんとなく意味が伝わってて、そんでなんとなく会話の流れがわかるかんじ
少なくとも自分の中で「レベルが高い」のと「レベルが低い」の区別はついてるからもういいや

というわけで茶化すなよ>>969-971

973 :デフォルトの名無しさん:2006/10/01(日) 13:30:19
改めて聞くが、
「いつも思うんだが、お前らの言うレベルの高いお話ってどんなお話?」


974 :デフォルトの名無しさん:2006/10/01(日) 13:59:29
>>964
>>966
お前、腐ったゴミだろ?
一回ぐらい死んでみたらどうだ?

975 :デフォルトの名無しさん:2006/10/01(日) 14:03:22
これまたレベルの低い煽りが来たな。

ボコボコにされたあと、腫れ上がった顔で後出し釣り宣言とかするタイプw

976 :デフォルトの名無しさん:2006/10/01(日) 14:47:29
>>975
子供の頃にマズイ食い物しか与えられなかったんだろう?
貧乏ヒマ無しだったんだな…
そんなに、ひねくれるな、おまえ!

977 :デフォルトの名無しさん:2006/10/01(日) 14:53:29
>>970-976
あのーすいません。
うだうだ馴れ合いはいいので、「レベルの高いお話」ってどんな話なのかさっさと誰か答えてくれません?

978 :デフォルトの名無しさん:2006/10/01(日) 14:55:46
質問なんですが最新のns2でのemulationを扱ってるサイトや本は無いでしょうか?
ns manualも大分古いですし、まとまった資料が欲しいのです

979 :デフォルトの名無しさん:2006/10/01(日) 15:05:33
>>977
気がついてないようですが、今話題の高慢な人が
話のレベルが高い・低いと勝手にランクづけしているだけです。

980 :デフォルトの名無しさん:2006/10/01(日) 15:13:32
そしてその傲慢な人は、私なんです

981 :デフォルトの名無しさん:2006/10/01(日) 15:24:53
傲慢?高慢?
レベルが低い話はいいかげんにしろ!殺すぞ!!

982 :969:2006/10/01(日) 15:40:35
結局レベル低い奴しかいないってことでFA?

983 :デフォルトの名無しさん:2006/10/01(日) 15:45:01
さあね、とりあえず高い奴もいるんじゃね?

984 :デフォルトの名無しさん:2006/10/01(日) 17:10:10
>>983 ん?殺すぞ!!

985 :デフォルトの名無しさん:2006/10/01(日) 17:25:04
金魚の糞よりもザコ>>976はどこに消えたんだ?

986 :デフォルトの名無しさん:2006/10/01(日) 17:25:50
まだボコボコやり足りないぞ!
出てこい。殺してやる!!

987 :デフォルトの名無しさん:2006/10/01(日) 17:33:22
>>977
DHT(Distributed hash tables)とかOSPFのアルゴリズムの話とか

988 :デフォルトの名無しさん:2006/10/01(日) 18:11:56
やっぱり俺だけが優越を味わえる高慢な話なんだね。
>>987死ね。

989 :987:2006/10/01(日) 18:13:16
次スレ立てたよ
ネットワークプログラミング相談室 Port18
http://pc8.2ch.net/test/read.cgi/tech/1159692799/

990 :デフォルトの名無しさん:2006/10/01(日) 18:17:21


991 :デフォルトの名無しさん:2006/10/01(日) 18:20:24
では>>987しねってことでスレ埋めますか?
言っとくけど、>>989は本人じゃないよ。

992 :デフォルトの名無しさん:2006/10/01(日) 18:22:16
こうして今日も

993 :デフォルトの名無しさん:2006/10/01(日) 18:23:11
またどうでもいいことで

994 :デフォルトの名無しさん:2006/10/01(日) 18:23:46
スレが消費されていく

995 :デフォルトの名無しさん:2006/10/01(日) 18:24:18
のであった
        .        .        .       .,
        .        .        .       .’
                                 ’
                                 .’
      .      .      .      .__、、、..========-、
                     、l゙? ̄`                   .`_
                     、l                      、’
                      .`  .  . . ..=-‐・ナ1          ’
                                                         .1
                                                         1
                 .        __、、...--─…・・ナナナナ^¨                 ’
                     ゙ ̄ ̄  . . .ソ . . . .ヘ                      .’
       .       .       .      .ン´      .’                     .}
                           ./        .1                    、i
                         ゙/     .    、’                    .i
                         ゙’           ・                   、j
                   .                  .’                   .j′
                          .             ’_      ___、、、.=-ー・・ナ^´
                           .              ̄ ̄ ̄ ̄

996 :デフォルトの名無しさん:2006/10/01(日) 18:28:57
順当に

997 :デフォルトの名無しさん:2006/10/01(日) 18:29:30
埋め

998 :デフォルトの名無しさん:2006/10/01(日) 18:30:22
ホント生産性の低いスレだよなぁ

999 :デフォルトの名無しさん:2006/10/01(日) 18:32:27
何も生産せずに埋め

1000 :デフォルトの名無しさん:2006/10/01(日) 18:32:59
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
///////////////////////////////////////
1000?

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

269 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)