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

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
主にソケットに関しての質疑応答スレッドです。

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

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

関連スレ
ネットワークプログラミング雑談
http://toro.2ch.net/test/read.cgi/tech/1235800707/
2デフォルトの名無しさん:2012/10/31(水) 21:07:02.24
過去スレ:
Port28 ttp://toro.2ch.net/test/read.cgi/tech/1334736934/
Port27 ttp://toro.2ch.net/test/read.cgi/tech/1293284816/
Port26 ttp://hibari.2ch.net/test/read.cgi/tech/1269343909/
Port25 ttp://pc12.2ch.net/test/read.cgi/tech/1255459388/
Port24 ttp://pc12.2ch.net/test/read.cgi/tech/1246895188/
Port23 ttp://pc12.2ch.net/test/read.cgi/tech/1230466044/
Port22 ttp://pc11.2ch.net/test/read.cgi/tech/1222603744/
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html
3デフォルトの名無しさん:2012/10/31(水) 21:07:49.38
図書コーナー:
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デフォルトの名無しさん:2012/10/31(水) 21:09:03.17
マスタリング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デフォルトの名無しさん:2012/10/31(水) 21:09:43.81
URL抜粋:
★規格
RFC 日本語版リスト
 http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
 http://rfc-jp.nic.ad.jp/link/
RFC Editor
 http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
 http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
 http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
 http://www.iana.org/assignments/port-numbers
6デフォルトの名無しさん:2012/10/31(水) 21:10:24.78
★プログラミング
C10K ヘヴィーロードサーバ
 http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
 http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
 http://www.whitefang.com/rin/
Java で packet capture
 http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
 http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
 http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
 http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
 http://X68000.q-e-d.net/~68user/net/
7デフォルトの名無しさん:2012/10/31(水) 22:06:48.57
8デフォルトの名無しさん:2012/10/31(水) 22:14:14.78
ではご相談を受け付けます。

最初の方、どうぞ。
9デフォルトの名無しさん:2012/10/31(水) 22:22:29.14
最近、なんだか元気がなくなってしまって・・・
10デフォルトの名無しさん:2012/10/31(水) 22:39:20.81
11デフォルトの名無しさん:2012/10/31(水) 22:43:48.75
その手のしまりのない肉塊を見ると、吐き気がするんだ・・・
12デフォルトの名無しさん:2012/11/01(木) 09:17:38.64
>1000
インターネットを創ったのは
LinuxじゃなくてBSD
これ豆な
13デフォルトの名無しさん:2012/11/01(木) 09:42:08.38
>>12
「インターネット」じゃなくて"Internet"
これまめな
14デフォルトの名無しさん:2012/11/01(木) 10:12:35.12
>>13
"Internet"じゃなくて"The internet"
これまめな
15デフォルトの名無しさん:2012/11/01(木) 10:28:28.78
BSDが作ったのはインターネットじゃなくてアーパネットじゃね?
16デフォルトの名無しさん:2012/11/01(木) 11:40:55.70
>>14
"internet"を挟むんだった、残念
17デフォルトの名無しさん:2012/11/01(木) 13:54:07.76
BSDが作ったのはSocketインターフェース
18デフォルトの名無しさん:2012/11/01(木) 18:35:47.78
最初期のインターネットにUNIXはあまり貢献してないです。
1980年くらいになってようやくUNIX上のサーバ実装が定着してきました。
それまでは370とかSDSとかPDPとか。
19デフォルトの名無しさん:2012/11/02(金) 01:14:02.89
Linux(CentOS6.3-x64)でルーティングをいじってて気づいたのですが
自身からルーティング不能なIPアドレスからパケットを入力した場合
OSにはパケットは届いても、プロセスまで到達しないようです。

OSが自身からルーティング不能のホストからの入力の場合には捨ててそうだ
というところまでは分かりました。
でもパケットそのものはせっかく届いているし
プロセスが受信できても良さそうなもんだな、と思ってしまいます。
この破棄動作は何か意味、というか意図が含まれているのでしょうか?
2019:2012/11/02(金) 01:17:41.31
例えば:
 [ホストA] <==> [L3SW] <==> [ホストB]
   ホストA(Linux): 192.168.1.1/24、*ルーティングの設定なし*
   L3SW: (左側)192.168.1.254/24 (右側)10.1.1.254/8
   ホストB: 10.1.1.1/8、defautGWは10.1.1.254
 1)ホストAで、UDPポート12345で受信待ち
 2)ホストBで、ホストAのUDPポート12345に送信
 3)ホストAにて、受信しない

・ホストAで、キャプチャするとパケットの入力は確認できます。
・netfilterにおいて、PREROUTNIGには到達しますが、INPUTにもFORWARDにも到達していないようです。
・ためしに、ホストAでルーティングを設定すると、プロセスはパケットを受信できる。
・ホストAでのルーティングは、本質的には到達不能な設定とかちょっと変でも受信できます。
 上の例いえば、default via 192.168.1.1/24 を設定する (自分自身がNexthop) とか。
21デフォルトの名無しさん:2012/11/02(金) 07:24:25.28
>>19
自分宛のパケットか判断する前の話?後の話?
22デフォルトの名無しさん:2012/11/02(金) 09:20:18.07
RPFじゃないの?
23デフォルトの名無しさん:2012/11/02(金) 10:33:50.16
ちょっと違う話かなと思うけど良かったらお願いします
DNSの安全性をチェックするプログラム書きたいんだけど基本的に問い合わせクエリに対するレスポンスを解析して安全性の基準と比較するって形なのかな
24デフォルトの名無しさん:2012/11/02(金) 10:40:55.80
DNSの何の安全性?
25デフォルトの名無しさん:2012/11/02(金) 11:11:54.12
基本的に外部からの脅威(キャッシュポイズニングとか)に対する安全性ですかね
例えばDNSサーバが再帰クエリを返すかとかポートがランダムかとかの判断をさせることになるはずだと思います
既にこういうサービスは結構あるといえばあるようだけど…

アクセスしてきた人の使ってるDNS判定してそこにチェック用のクエリを送ってそのレスポンスで判断という流れになるのかなって
安全かどうかの基準はRFCをよく確認する必要がありそう
26デフォルトの名無しさん:2012/11/02(金) 11:26:27.45
何が質問したいのかわかってない質問者に何を答えろと?
27デフォルトの名無しさん:2012/11/02(金) 11:30:06.13
DNS関連のRFC読んでたらそれだけで3ヶ月はかかると思われ
28デフォルトの名無しさん:2012/11/02(金) 11:31:19.01
>アクセスしてきた人の使ってるDNS判定して

そんなこと出来るのか
すげー
29デフォルトの名無しさん:2012/11/02(金) 11:32:27.60
質問の趣旨も理解せずに主義を語るのが病気持ちプログラマの特徴
30デフォルトの名無しさん:2012/11/02(金) 11:53:49.39
DNSのポートってランダムなの?
31デフォルトの名無しさん:2012/11/02(金) 12:09:35.16
>>30
送信元ポートをクエリごとにランダムにすることで攻撃の成功率を下げる意味がある
32デフォルトの名無しさん:2012/11/02(金) 12:20:17.70
>>30
ランダムにするのはクライアント側の話な。
33デフォルトの名無しさん:2012/11/02(金) 13:37:32.45
    ,.. '"  ,:   ̄ ヽ 、、    
   ,.' , /. / l |、 、:::::::゙'.    
  l ,' iー-'、 ヽ;゙ー- l、:.:::::::│   
  l !//lんl  lん:lY`:i :、 :│  
  lヘj、 V:リ  V::リノ、:| lナ │  
   〈 "     ¨ " | レ゙::│    かれのあたまのなかわかるんだけど 
   l>...._ 、ー-、 _,.ィV::::: i   
    |:::::,イヽ:又 ̄ヽ' ::::::::│
    |:/ ゝヽ∨/'  ヽ::::::│  
    /           ヽ:| 
34デフォルトの名無しさん:2012/11/02(金) 23:27:21.28
libnetlinkについての日本語の情報(ブログ,本等)ないかなぁ. スレチか...
35デフォルトの名無しさん:2012/11/03(土) 02:01:10.12
>>22
どうやら当たりでした。
なるほど。ありがとうございます。
36デフォルトの名無しさん:2012/11/15(木) 10:17:28.59
漠然とした質問ですので、適当にアドバイスお願いいたします。

これからモバイル(スマホやタブレット端末)相手のソフトを作ろうと考えています。
アプリは社内システムの延長です。
社内システムはC++BuilderとSQLServerでシコシコ10年以上やってきました。
なんだか浦島太郎みたいなおじさんですが、いろいろ調べてAdobeのFlashBuilderで
やるのが簡単そうだ、ということで使用ライセンスを得ました。
で、端末相手のサーバーはどうする?
ということでC++Builderに付属のIndyコンポーネントを初めていじっていけそうな感触を得ました。
スレッドを意識しなくても書けそうです。
しかし、ここから進みません。
どういうプロトコルで上位のデータのやりとりをするのが合理的かということです。
WebサービスだのSOAPだのちんぷんかんぷんです。
37デフォルトの名無しさん:2012/11/15(木) 10:30:58.51
Flashはオワコン
38デフォルトの名無しさん:2012/11/15(木) 10:38:48.63
やる気がありませんと言ってる奴に何をアドバイスする事があると言うのか
39デフォルトの名無しさん:2012/11/15(木) 16:28:18.57
>>36
すきにすれば
40デフォルトの名無しさん:2012/11/15(木) 16:31:18.35
HTTPベースのサーバアプリ書いてもいいし、TCP/IPベースの独自サーバ書いても何やってもできそうなもんだが。
おじさんになると、検索もできないし、書店に行くこともできなくなるのか。やだやだ。
41デフォルトの名無しさん:2012/11/15(木) 18:03:27.18
>>36
クライアントはブラウザで。
42デフォルトの名無しさん:2012/11/15(木) 18:08:50.66
>>40
最初はその独自サーバーで行こうかと考えましたが、
もっと定型的で簡単な方法があるのかなと調べている途中でした。

昔のDOS時代にもモデムを使って独自のフォーマットで
やりとりした事があるのですが、あんまり練った仕様じゃなかったので
簡単な拡張もできなかった経験があります。

どうもお騒がせしたしました。
43デフォルトの名無しさん:2012/11/15(木) 18:22:19.68
>>42
> 最初はその独自サーバーで行こうかと考えましたが、
> もっと定型的で簡単な方法があるのかなと調べている途中でした。

「独自サーバー」の通信部分は定型的で簡単に書けます。
誰が書いても、通信部分はまあ似たようなものになるでしょう。方式は何パターンかありますが。
要するに、Socketを使ったサーバアプリを書いたことないってだけでしょ。

> もっと定型的で簡単な方法

が、HTTP上にのっけるアプリなんですが。
どんな言語でも"Hello, World!"を返すぐらいのレベルなら、すぐに作れるでしょう。
HTTPを返すのが嫌なら、JSONを返したり。

> いろいろ調べて

いや、調べてないでしょ。あるいは壊滅的に調べるのが下手とか。
本屋行きなさいよ。
44デフォルトの名無しさん:2012/11/15(木) 20:00:53.08
浦島じいさんなのだろう
45デフォルトの名無しさん:2012/11/15(木) 22:44:52.57
>>40-44
おまえら餌もついてない釣り針に食いつくタイプだろ?
46デフォルトの名無しさん:2012/11/16(金) 01:52:22.23
これが後釣り宣言という香具師か
47デフォルトの名無しさん:2012/11/16(金) 13:37:27.61
>>43
どうも、ありがとう。
あれからFlash Builderの側(クライアント)を調べたら素のTCP/IPの選択肢はありませんでした。
HTTP、PHP、XML、Webサービスとあと聞いたことないやつ3点のどれかです。
お粗末さまでした!
48デフォルトの名無しさん:2012/11/16(金) 14:24:37.29
もう、自分が何を言ってるのかもわからない状態。
49デフォルトの名無しさん:2012/12/15(土) 16:40:50.41
初歩的な質問かと思いますがよろしくお願いします。環境はWindows7, Visual c++2010です。

proxyサーバー越しにネットワークに接続するにはどうすれば良いでしょうか。

現在は、単純にSOCKETを作って、サーバーにconnectしてGET メッセージを送るという方法を使用しています。
しかし、今後はproxyサーバー越しに、ネットワークに接続する必要が出来ました。

proxyサーバーを介する場合、接続先サーバーをproxyサーバーにして、本当に接続したいURLをGET以降に
記述したらいいということまではわかりました。
しかしユーザー名とパスワードの必要なproxyサーバーのため、usernameとpassをどのように設定すればよいか
解りませんでした。
ユーザー名とパスワードを入れずにそのまま接続すると、やはり HTTP 407 が帰ってきます。
50デフォルトの名無しさん:2012/12/15(土) 16:59:22.13
プロキシサーバを構築された方に相談して下さい。
第三者には認証の仕組みが解らないのでアドバイスが困難です。
51デフォルトの名無しさん:2012/12/15(土) 21:59:27.49
>>49
IE とかなら接続できるんでしょ?
なら、wireshark とかでパケット見ればいいんじゃね。
52デフォルトの名無しさん:2012/12/19(水) 23:17:11.99
rfc 2617 を読め、とマジレスしてみる。
53デフォルトの名無しさん:2012/12/22(土) 00:19:44.92
生データからアプリケーションプロトコルをデコードしたいんだけどよくわからない
クラスでプロトコル定義するのにどういう風に設計したらいいのだろう
単純にunpackして分割してみたりはした
54デフォルトの名無しさん:2012/12/28(金) 23:20:36.44
おーい、エスパー
55デフォルトの名無しさん:2012/12/29(土) 20:15:18.48
無理!
56デフォルトの名無しさん:2012/12/29(土) 23:54:31.53
エスパーじゃないけど, 挑んでみる

> 生データからアプリケーションプロトコルをデコード
暗号買得と一緒で, パーターン解析して頻度計算すれば
運が良ければヘッダーくらいは抽出できるかも知れない

> クラスでプロトコル定義する
インタプリタパターンってのが王道らしいぞ

yacc とか bison とか(じゃなくてもいいけど, オートマトン
ジェネレータ的なもの)使えばもっと楽できるかも

おそらく, 全然, 別の話なんだろうな w
57デフォルトの名無しさん:2013/01/01(火) 01:49:27.21
エスパーとかいうまでもなく言葉通りパケットの生データから中身を解析するって話だろ
tcpdumpとかwiresharkみたいに
オブジェクト指向の言語で同じことするのに設計というか実装するのに悩んでるんじゃないの?
58デフォルトの名無しさん:2013/01/01(火) 09:43:35.59
買得w
59デフォルトの名無しさん:2013/01/08(火) 12:04:02.25
60デフォルトの名無しさん:2013/01/08(火) 12:10:55.49
上ミス

IOCPでUDPの送受信って出来ないのかな
ネットでサンプル探してるがTCPしか見つからん
自分でいろいろ組んでみたんだけど送信した後にGetQueuedCompletionStatusがエラー返してくる
受信する相手がいる場合はエラーにならない。相手がいない場合だけエラーになる。
もしかしてTCPみたいに接続が確立されてないと使えないのかな?
61デフォルトの名無しさん:2013/01/08(火) 12:24:56.58
>>60
できる
ソケットのみで送受信できるようにbindしておくよろし
62デフォルトの名無しさん:2013/01/08(火) 12:39:08.79
OSはまあ関数名でわかるけど、
(AIXもIOCPはあるんやで)
どんなエラーか書いてね。
それから相手ポートが閉じてる時にどうなって欲しいの?
63デフォルトの名無しさん:2013/01/08(火) 14:38:31.89
受信もしてるからbindはしてる
返ってくるエラーはERROR_PORT_UNREACHABLE
相手がいてもいなくても、ただ単純に受信待ちしつつ周期でデータ送りたいだけ
64デフォルトの名無しさん:2013/01/08(火) 14:54:34.79
port unreachableならTCPでも同じ。
コード書いてリトライしてください。
65デフォルトの名無しさん:2013/01/08(火) 15:18:10.84
そうかー。とりあえずエラー無視して続行しても大丈夫みたいなんだよね。
IOCPのハンドル閉じるまで処理巻き戻しとかしなくていいんであれば無視でいいかな・・・
66デフォルトの名無しさん:2013/01/13(日) 01:43:26.26
ローカルなファイルへの書き込みをするときのように
write(client)からclose(client)の間にfflush(client)をするべきでしょうか?
67デフォルトの名無しさん:2013/01/13(日) 01:56:39.27
そうまでして省く必要があるのか?
68デフォルトの名無しさん:2013/01/13(日) 13:40:48.75
close()はflush()もしてくれるだろ
69デフォルトの名無しさん:2013/01/13(日) 15:03:21.83
そもそもsocketにbuffer flushは無いだろ
気にせせずcloseして帰り値は捨てて良い
ネットワークアプリケーションは信頼性が低いというのは、知識に欠けるユーザーでも信頼性が低いと知ってるから、エラーがでてもあまり気にしない
70デフォルトの名無しさん:2013/01/13(日) 15:10:22.41
>>69
>気にせせずcloseして帰り値は捨てて良い

こういう奴が作るネットワークアプリケーションの信頼性は低いんだろうな。
71デフォルトの名無しさん:2013/01/13(日) 15:50:01.05
すいません
結局のところバッファの掃き出しはどうすべきなんでしょうか?
72デフォルトの名無しさん:2013/01/13(日) 16:44:12.28
プロトコルで終わりが決められてるんでもなけりゃ
いくらフラッシュしたところで閉じるまでにまたデータ来るかもしれんし
閉じる必要があるときに閉じるだけでいいだろ。
73デフォルトの名無しさん:2013/01/13(日) 16:49:39.38
気になるならするべき
74デフォルトの名無しさん:2013/01/13(日) 16:53:04.62
>>72
> いくらフラッシュしたところで閉じるまでにまたデータ来るかもしれんし

意味がわからん。
ひょっとして受信側で flush するとかしてるのか?
75デフォルトの名無しさん:2013/01/13(日) 18:45:01.08
その前にflushするAPIなんてあったか?見たこと無いぞおれ
76デフォルトの名無しさん:2013/01/13(日) 18:55:33.43
flush する API じゃないけど, setsockopt で SO_LINGER と
TCP_NODELAY を突くくらいかなぁ
77デフォルトの名無しさん:2013/01/13(日) 19:01:28.37
あと, 到達確認的な意味だと
送り側 shutdown(..., SHUT_WR)
|
v
受け側 if (read(...) == 0) { shutdown(..., SHUT_RDWR); }
|
v
送り側 if (read(...) == 0) {shutdown(..., SHUT_RD); }
とか, かなぁ
78デフォルトの名無しさん:2013/01/14(月) 02:36:54.80
クライアントのソケットで、同じポートにbindしてもエラーにならないんだけど、これってやってもおk?
下のコードの後、別々のところにconnectしても普通に通信続けられるみたいだけど。
仕様上の理由でポート固定なんだ。

local.sin_port = htons(12345);

SOCKET sock1 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
SOCKET sock2 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

int on = 1;
setsockopt(sock1, SOL_SOCKET, SO_REUSEADDR, (char*)&on, sizeof(on));
setsockopt(sock2, SOL_SOCKET, SO_REUSEADDR, (char*)&on, sizeof(on));

bind(sock1, (sockaddr*)&local, sizeof(local));
bind(sock2, (sockaddr*)&local, sizeof(local));
79デフォルトの名無しさん:2013/01/14(月) 03:47:55.15
ok
80デフォルトの名無しさん:2013/01/14(月) 16:57:55.78
>>78
TCPのstremは、
<src addr, src port, dst addr, dst port>
の四つ組で識別される。つまりひとつでも違えば別のstream。
81デフォルトの名無しさん:2013/01/15(火) 21:33:07.75
>>79, 80
そういうことか、わかった。
82デフォルトの名無しさん:2013/01/15(火) 22:23:39.87
ひょっとしてTCP/IPの勉強をしても
socketプログラミングにあまりはやくに立たないんですか?
83デフォルトの名無しさん:2013/01/15(火) 23:36:48.62
役に立つわ
84デフォルトの名無しさん:2013/01/16(水) 02:42:24.01
甘利早くも役に立たない。ちくしょ〜ユーロ円が台無し
85デフォルトの名無しさん:2013/01/16(水) 03:47:25.08
>>82
TCP/IPの知識が無ければ、Socketを使ったTCP/IPプログラムでトラブルが
発生したときに、原因を究明することは出来ないだろうな。
86デフォルトの名無しさん:2013/01/16(水) 07:36:48.74
>>84
計算しょうか
87デフォルトの名無しさん:2013/01/18(金) 14:02:30.24
他人の通信の傍受ってどうやるんですか?
88デフォルトの名無しさん:2013/01/18(金) 14:04:29.67
>>87
他人の通信を傍受すればできます。
89デフォルトの名無しさん:2013/01/18(金) 14:24:29.60
>>87
スイッチのバッファをあふれさせる
90デフォルトの名無しさん:2013/01/18(金) 18:00:48.87
>>84
ニューロコンピュータ?
91デフォルトの名無しさん:2013/01/18(金) 20:20:39.65
サブネット内ならARP PROXYでトラフィックを誘導する
92デフォルトの名無しさん:2013/01/18(金) 21:19:42.25
>>87
他人の背後で画面を覗き込む。
93 ◆wSaCDPDEl2 :2013/01/18(金) 23:02:26.89
てst
94 ◆wSaCDPDEl2 :2013/01/18(金) 23:04:16.41
2chのdat読み込むとトリップ付けたときの名前が</b> ◆wSaCDPDEl2 <b>のように<b>タグで囲まれてるんだけど
普通<b> ◆wSaCDPDEl2 </b>じゃないですか?
なんで逆になってるんですかね?
95デフォルトの名無しさん:2013/01/19(土) 00:22:28.22
</b>したいからです。
96デフォルトの名無しさん:2013/01/19(土) 00:53:03.70
名前は<b>タグで太字表示になっている。
トリップは標準フォントになっている。
で、名前をつけないでトリップだけつけるから名前の<b>タグを
閉じるために頭に</b>がつけてあるんだと思われる。
97デフォルトの名無しさん:2013/01/19(土) 00:55:49.45
なるほど
わかりましたありがとうございます
98デフォルトの名無しさん:2013/01/19(土) 09:04:34.79
>>90
県央の土権屋のことだろう
99デフォルトの名無しさん:2013/01/19(土) 12:10:58.99
マイiPhoneからのみアクセスを許可したサーバーを構築したいのですが
マイiPhoneを識別するにはどうすれば良いとおもいますか?
100デフォルトの名無しさん:2013/01/19(土) 12:47:33.82
つ認証
101デフォルトの名無しさん:2013/01/19(土) 12:48:37.24
証明書を発行してインストールする
102デフォルトの名無しさん:2013/01/19(土) 13:15:28.65
sslでユーザ証明書に途中からする時って脆弱性なかったっけ。
103デフォルトの名無しさん:2013/01/19(土) 16:48:41.16
>>102
> 途中からする

kwsk
104102:2013/01/19(土) 21:46:04.98
>>103
CVE-2009-3555 SSL renegotiationによる脆弱性のこと。
apache2.2ではSSLInsecureRenegotiation onにしとかないと、あるディレクティブだけのユーザ証明書使えなかった。
このオプションはInsecureとあるように、脆弱性を受け入れられる場合しか使えない。
今、どうなってるのかは知らない。
105デフォルトの名無しさん:2013/01/19(土) 21:51:29.65
>あるディレクティブだけのユーザ証明書

この考え方自体がSSL/TLSに対する挑戦だな
106102:2013/01/19(土) 21:58:42.35
>>105
どこでもユーザ証明書を要求してれば問題なかったのかな?

とっくに直ってるか。
Changes with Apache 2.2.15 March 5, 2010
SECURITY:: CVE-2009-3555
107デフォルトの名無しさん:2013/01/19(土) 22:03:23.73
やけに古い話だな。
RFC 5746に対応してない糞クライアントなら今も問題になりうるが、
元のお題が個人利用だし想定する必要はない。
108102:2013/01/19(土) 22:36:58.74
>>107
その仕事しに客先行ったのは最近なんだけどなwセキュリティパッチくらいあてて欲しい。
109デフォルトの名無しさん:2013/01/20(日) 18:31:59.78
ローカルホストのアプリが送信してるデータ、たとえばブラウザのGETメソッドとそのヘッダーとデータ見てみたいんですが
ブラウザのプロクシをローカルホストに設定するなどしないと不可能ですか?
プロクシを設定するないアプリの通信を監視するにはどうすればいいんでしょうか?
110デフォルトの名無しさん:2013/01/20(日) 18:38:02.67
wiresharkとかでみれば?
111デフォルトの名無しさん:2013/01/20(日) 19:05:20.00
>>109
UAみたいだことかなら、ncで適当なポートにサーバ立てて受け付ける。やりとりが見たい時はwiresharkかtcpdump。ncがteeみたいに使えたら便利だし、既存なのかな。
112デフォルトの名無しさん:2013/01/20(日) 19:08:50.93
>>110,111
ありがとうございます試してみます
まだはじめたばかりなんですがネットワークはデバッグが大変ですね
113デフォルトの名無しさん:2013/01/20(日) 19:45:29.72
>>112
キャプチャで簡単に全部見えるのだから、標準的なデバッガのない内部バスなんかより良いと思うのだが。
114デフォルトの名無しさん:2013/01/21(月) 08:29:05.87
禿
115デフォルトの名無しさん:2013/03/08(金) 00:14:52.55
Wiresharkで特定ポート宛のTCP SYNを捕まえて処理するDissectorを書こうと
しているんだが、"tcp.port"のDissectorTableに登録してもESTABLISHED以降の
パケットしか届かない。
SYNを処理するには"ip.proto"に登録して自分でポート番号を判断するしかないんだろうか?
もしそうだとして、TCPヘッダのデコードも自分でやらなきゃならないのかな。
116デフォルトの名無しさん:2013/03/08(金) 14:09:47.53
>>115
SYNのビットを見りゃいーじゃん
117デフォルトの名無しさん:2013/03/08(金) 14:10:54.12
ごめん、勘違いしてた
118デフォルトの名無しさん:2013/03/25(月) 14:31:30.15
TCPで100バイトのデータを送ろうとしています。
50バイトを送ったところで回線に不具合が起きて自動的にセッションが張りなおされました。
この場合、データの続きは51バイト目から送られますか?1バイト目から再送されますか?
119デフォルトの名無しさん:2013/03/25(月) 14:51:51.28
どこまでACKもらったかによるのでは
120デフォルトの名無しさん:2013/03/25(月) 15:05:59.94
つまりACKを送る前で切れてると
でもACKって回線が切れる前に送ったかどうかわからないよね??
121デフォルトの名無しさん:2013/03/25(月) 15:07:07.56

反応無かったら何度も送るか
つまり51バイト目からになるのかな
122デフォルトの名無しさん:2013/03/25(月) 15:10:02.34
間違えたわ
ACKは古いセッションに送るのか
新しいセッションはどこまで送れてるのかわからないのに51バイト目から再開してくれるのかな??
123デフォルトの名無しさん:2013/03/25(月) 15:22:30.34
不明な時は前から送るだろうし、受け取った方は同じもの2つ受けても
大丈夫なように動作するだろう。
124デフォルトの名無しさん:2013/03/25(月) 15:27:16.58
セッションIDって通信内容に含まれてるの?
じゃないと前のセッションがどれかわからないよね?
125デフォルトの名無しさん:2013/03/25(月) 16:17:29.23
どのレイヤーの話なの?
126デフォルトの名無しさん:2013/03/25(月) 16:40:27.67
初心者すぎてよくわからん
途中で何かトラブルがあった場合、別のポートから続きが送られてくることもあるって理解で合ってますか?
127デフォルトの名無しさん:2013/03/25(月) 16:45:06.67
そのポートってのは何だよ
128デフォルトの名無しさん:2013/03/25(月) 16:48:13.00
>>126
あってません
もういちど、自分の手で、続きを送れ
129デフォルトの名無しさん:2013/03/25(月) 16:56:26.81
サーバと一般のPCの間のインターネットの通信で
回線が不安定になっても自動的に繋ぎなおされることは無いってこと?
130デフォルトの名無しさん:2013/03/25(月) 16:57:01.53
TCPの中の人が何を何度再送してようと、それはアプリから見えない水面下のことなので、気にする必要ない
100バイト送ったなら100バイト届くし、その間にポートが変わるようなことはない

TCPの中の人がギブアップするようなトラブルが起きたら、切断されてエラーになる
そのようなエラーが起きたときは、自動的に接続が貼り直されることはないし、自動的に別のポートから続きが送られることもない
131デフォルトの名無しさん:2013/03/25(月) 17:01:09.78
それだ
ありがとうございました
132デフォルトの名無しさん:2013/03/25(月) 17:02:33.34
そのレベルの話だと見破れる>>130スゲー
133デフォルトの名無しさん:2013/03/25(月) 17:04:07.10
スゲーとか言うなよ情け無い
134デフォルトの名無しさん:2013/03/25(月) 17:04:33.62
じゃあ繋ぎっぱなしのTCPってクライアントにIDを割り振らなくてもセッションから個人を識別できるってことか
135デフォルトの名無しさん:2013/03/25(月) 17:13:22.43
せめてネスペを取ってから来て
136デフォルトの名無しさん:2013/03/25(月) 17:25:03.88
そんなんじゃ NHN に雇ってもらえないぞ
137デフォルトの名無しさん:2013/03/25(月) 20:54:31.05
>>134
性善説ならば
138デフォルトの名無しさん:2013/03/25(月) 20:55:50.77
最近はTCPのGraceful Restartができるらしいが。
139デフォルトの名無しさん:2013/03/25(月) 22:07:05.43
MMORPGの作り方についての質問はここでいいですか?
140デフォルトの名無しさん:2013/03/25(月) 22:25:49.90
ゲ作板のほうがいいんじゃないかね
141デフォルトの名無しさん:2013/03/26(火) 00:10:17.03
あそこ過疎だし厨房しかいないし機能してないじゃん
板名に「技術」って付いてるけとその実態は技術板じゃなくて企画板じゃん
142デフォルトの名無しさん:2013/03/26(火) 05:07:38.28
ってことはここでいいってことだな
143デフォルトの名無しさん:2013/03/26(火) 05:57:20.66
>>142
まぁ、MMOのネットワーク限定ならな・・・
144デフォルトの名無しさん:2013/03/26(火) 20:25:12.04
質問ですMMORPGの通信はどうやってやってるんですか?
145デフォルトの名無しさん:2013/03/26(火) 20:46:14.28
本屋さんにそういう本が売ってるから買ってきなさい
アマゾンでも楽天でもいいぞ
146デフォルトの名無しさん:2013/03/26(火) 22:09:02.13
>>144
MMORPG でググレば、いくつか解説サイトは見つけられるけど、
いったい何が分からないの?

・dyama's web page: MMORPG/Protocol
 http://dyama.chaosnet.org/index.cgi?MMORPG/Protocol
  -- ごく簡単な解説(日本語)

・Description of the game protocol
 http://code.google.com/p/galaktia/wiki/Protocol
  -- MMORPGをベースにしたゲームプロトコルの詳細な解説
    Pythonによるサンプルコード付き(英語)

・MMORPG プロトコル エンコードの解読
 http://ja.softuses.com/92917
  -- MMORPGプロトコルをリバースエンジニアリングする技法を解説(日本語)

TCPソケットの経験があって技術英語の読解力があればそれほど難しくないから、
高校生レベルの課題のように見えるが.....
147デフォルトの名無しさん:2013/03/29(金) 22:10:35.43
ここの住人は、メールソフトは既存のソフトを使うのか。あるいは、
自作するのか。その辺が知りたいな。
148デフォルトの名無しさん:2013/03/29(金) 23:14:22.33
>>147
> メールソフトは既存のソフト
ユーザーエージェントのことでOK?
だったら, 既存のものを使う
# 自分用にカスタマイズできればそれでOK
149デフォルトの名無しさん:2013/03/30(土) 01:23:27.32
MUAならwl使ってるわ。
150デフォルトの名無しさん:2013/03/30(土) 03:53:56.60
>>147
既存のソフトで事足りるから既存のソフトを使ってる
それに通信部分は余裕でもメーラーとしての便利な各種機能を実装するのが面倒
アドレス帳とか、メールの検索とか、自動振り分けとか、etc...
一つ一つは実装しろって言われたらできるけど、全部実装するのは面倒
151デフォルトの名無しさん:2013/03/30(土) 15:44:58.01
昔はmew, 今はgmail。
どっちもelispとjavascript(browser addon)でカスタマイズ。
152デフォルトの名無しさん:2013/03/30(土) 16:52:03.33
gmailとか解析エンジンが中身読んでるから嫌だよ
153デフォルトの名無しさん:2013/03/30(土) 17:54:14.11
>>152
メールを読まれてる可能性はどこも一緒だから
それを懸念するなら母数が多いところのほうが安全だろ
154デフォルトの名無しさん:2013/03/30(土) 18:18:33.61
暗号化しろよ
155デフォルトの名無しさん:2013/03/30(土) 18:59:21.53
>>154
サーバに言えよ
156デフォルトの名無しさん:2013/03/30(土) 19:22:20.95
>>153
母数が多いところを選ぶのは安全だが
選ばないという手もある

そんな俺は自宅メールサーバーを立てたよ

相手側のサーバーは避けられないからそれは仕方ないけど、母数とかって話が出たから確率論でいくと、
「どちらか一方のサーバーで解析される確率」より
「相手のサーバーで解析される確率」のほうが必然的に低いわけだから
後者の自宅サーバーのほうが安全

自宅メールサーバーマジオススメ
157デフォルトの名無しさん:2013/03/30(土) 19:38:06.01
アホだな。
158デフォルトの名無しさん:2013/03/30(土) 22:13:30.88
>>156
金が結構かかるじゃん。
159デフォルトの名無しさん:2013/03/30(土) 22:45:38.67
>>155
何を言っているんだ。
サーバで見られること気にしてるのに、サーバで、またはサーバとの通信を暗号化しても意味ないだろ。
S/MIMEとかMUA間でメッセージを暗号化するんだよ。
160デフォルトの名無しさん:2013/03/30(土) 22:49:41.12
>>158
このスレの住人ならドメインと自鯖くらい持ってるだろ。まあセカンダリを分けるとなると大変だけど。
161デフォルトの名無しさん:2013/03/30(土) 23:14:59.53
>>159
メールを暗号化してもPGP作った人みたいにFBIに追いかけられませんか?
162デフォルトの名無しさん:2013/03/31(日) 12:01:43.31
>PGP作った人みたいにFBIに追いかけられ
どういうこと?w
詳しくw
163デフォルトの名無しさん:2013/03/31(日) 18:38:40.95
164デフォルトの名無しさん:2013/03/31(日) 18:56:08.59
輸出規制の制度の隙間を縫って輸出するような真似をするからだよ。
書籍は規制対象外なのを利用して、本として持ち出して、
スキャナで取り込むとかしたんだっけ?
165デフォルトの名無しさん:2013/04/03(水) 00:05:18.98
UDPを利用して特定のポートにデータを送信する場合、
受信者がいなければ、行き場を失ったデータはどこへ行くのか?

一定数はキューみたいなものに保存されるのかしら?
それとも逐一消えていくのかしら?

前者の場合、リアルタイムシステムに悪影響を与えてしまうと思うけど、どうなんでしょう。
初心者でスマソ
166デフォルトの名無しさん:2013/04/03(水) 00:10:51.44
初心者お断り
167デフォルトの名無しさん:2013/04/03(水) 00:18:11.89
>>165
受信ソケットの話かルータのIPの話かわからないが破棄すればいいだろ。いないってなんだ。
168デフォルトの名無しさん:2013/04/03(水) 00:35:39.78
申し訳ない、ソケットの話ね。

"1"というデータを送信、250msec待つ
次は"2"というデータを送信、待つ

という送信プログラムと、
特定のポートにアクセスしてデータを所得するプログラム

を書いてみたんだけど、送信プログラムをしばらく走らせてから受信プログラムを走らせても、
すでに消え去ったと思われる1というデータを取得してしまう。
169デフォルトの名無しさん:2013/04/03(水) 00:40:59.53
icmpってのがあるが、
icmpで反応があることを期待してはいけない。
相手が生きているか死んでるかはっきりしないのが分散システムの基本。
170デフォルトの名無しさん:2013/04/03(水) 01:06:41.67
>>168
本当に受信者居ないの?
もしかしてパソコンの電源が入ってない?
171デフォルトの名無しさん:2013/04/03(水) 11:19:05.08
>>170
送信相手がいないと確定してるときって送信しないんだっけ?
UDPは気にせず送信しちゃうんじゃないの?
172デフォルトの名無しさん:2013/04/03(水) 12:31:35.65
プログラムがどこでブロックしてるか確かめながらやってみそ
173デフォルトの名無しさん:2013/04/03(水) 13:00:01.31
>>171
気にせず送信すると思う。

>>172
プログラム側に問題があるのかな…
OS側のバッファのせいとしか思えない…
174デフォルトの名無しさん:2013/04/03(水) 13:05:27.61
>>165
捨てられるだけだよ
175デフォルトの名無しさん:2013/04/03(水) 13:32:21.38
>>173
試しに1じゃなくて送信時刻を送ってみては
176デフォルトの名無しさん:2013/04/03(水) 14:19:03.34
全てが正しく動いているなら、ICMP port unreachが送信したホストに返る
177デフォルトの名無しさん:2013/04/03(水) 19:24:47.39
>>175
サンクス
5秒ほど遅れてた…
178デフォルトの名無しさん:2013/04/03(水) 21:56:32.66
自己解決しますた…

受信プログラムを待機させている間にソケットにポート設定をしてたのが原因みたい

よくワカンネ
179デフォルトの名無しさん:2013/04/04(木) 11:58:03.35
>>178
ふざけんなよ!
>送信プログラムをしばらく走らせてから受信プログラムを走らせ
って書いてたよな? 適当なことを書きやがって


ポートをバインドした時点で受信は開始されます
カーネルにバッファされます
180デフォルトの名無しさん:2013/04/04(木) 12:12:58.81
ワロタ
181デフォルトの名無しさん:2013/04/04(木) 13:30:39.19
>>178
死ねよおまえ
生きてる価値ねーよ
182デフォルトの名無しさん:2013/04/04(木) 13:57:20.53
プロトコルスタックさんの気持ちになって考えればすぐにわかることだろうに
なにが「よくワカンネ」だ
183デフォルトの名無しさん:2013/04/04(木) 22:09:15.34
馬鹿は馬鹿とは自分では認識できないということだな
184 忍法帖【Lv=2,xxxP】(2+0:5) :2013/05/11(土) 23:27:23.69
ほしゅ
185デフォルトの名無しさん:2013/05/13(月) 21:29:52.72
久しぶりにwinsock使ったら面倒くさかった。
ここ数年C#にどっぷりつかってたから、C++でコーディングするのが面倒だった。
実行環境のことを考えなくてよいなら、C#やJavaで作る方が簡単だな。
186デフォルトの名無しさん:2013/05/13(月) 21:34:47.80
JavaはHttpURLConnectionで事足りるレベルなら簡単だけど
Socket作るんだったらたぶんC#のほうが簡単そう。
187デフォルトの名無しさん:2013/06/01(土) 23:20:34.89
質問ですが
select(2)の第一引数には結局何を渡せば良いのん?

バークレーソケットの場合、FD_SETSIZEを渡しとけば機能的には問題無いらしいが、
これは例えばFD_SETSIZEが32768の環境なら、select()を呼ぶたびに
32768個のディスクリプタがチェックされることになるので無駄が生じている気がする…

あとWinsockではFD_SETした個数を渡せば良いというのは本当ですか
188187:2013/06/01(土) 23:24:31.90
ああWinsockについては自己解決しました、
ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx
>nfds [in]
>Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
→ガン無視されるので0とか-1とか渡しても良い(適当)

バークレーソケットではどうなのですか
189デフォルトの名無しさん:2013/06/01(土) 23:49:25.06
一番大きいfd+1
190187:2013/06/02(日) 00:00:57.31
>>189
レスdクス、
select(2)を呼ぶ時点でFD_SETされているのはソケット番号であってディスクリプタ番号ではなく、
ソケット番号がディスクリプタ番号と一致するとは限らないと思うのですが、それでも?
実はバークレーソケットでは一致するのでしょうか
(C標準ライブラリのIOBとかの実装と同じで、
 ハンドル==配列の添え字、とする実装のが自然とは思えますが、仕様としてどうなの?)
191デフォルトの名無しさん:2013/06/02(日) 00:15:20.65
socket(2), open(2)が返すのはfd。
fdは全部数字。
「ソケット番号」という概念はない。
192デフォルトの名無しさん:2013/06/02(日) 00:50:32.12
>>191
レスdクス多分理解しました
バークレーソケットの場合は全部fdなので問題は無い、と、

ただ、サーバ側のプログラムでは、クライアントから新規接続cがあった場合、
listenしていたfdをaccept(2)に渡して接続c用の新規fdを取得する結果、
select(2)で待つべきfdが増殖していくと思うのですが、
ということは<一番大きいfd+1 >というのはそのつど更新していくもの?
それとも、通信プロセスを起こすタイプのマルチスレッドサーバにすると問題無い(普通はそうする?)のでしょうか…

あと関連質問なのですが、
通信「スレッド」を起こすタイプのマルチスレッドサーバではどうすれば良いのでしょう…
子プロセスにfdを渡すのと異なり、親がfdを閉じるわけには行かない
しかし親だけがselect(2)するのでは通信「スレッド」を起こす意味がない
また、実情はともかく、仕様上はWinsockはスレッドセーフとは謳われていない
(Winsock互換の非スレッドセーフな実装が理論上は有り得る)
ので、どうプログラミングするのが正しいのかいまいちわからん…
193デフォルトの名無しさん:2013/06/02(日) 03:49:28.43
そりゃ更新しないと意味ないわな。

マルチスレッドサーバならselect(2)は使わなくていいでしょ。
いろいろな混合モデルもあるけど、最初は簡単なモデルで。
194デフォルトの名無しさん:2013/06/02(日) 09:34:05.28
何バイト送られて来るかわからない通信でselect→1バイトずつreadと言うのはやるべきじゃないってmanに書かれてたけどどうするのが一番効率的なんでしょう。
mtuの値を取得してその値-フレーム分をreadするのでしょうか?
195デフォルトの名無しさん:2013/06/02(日) 10:54:39.80
そりゃ 1MB 受け取るのに百万回繰り返さなきゃいかんようではお世辞にも効率いいとは言えまい
ノンブロッキングモードにして適当に大きなサイズ (8KB とか 64 KB とか) で読めばいい
196デフォルトの名無しさん:2013/06/03(月) 01:05:59.71
ノンブロッキングにする必要はない。
197デフォルトの名無しさん:2013/06/03(月) 01:16:29.85
selectしているのはブロッキングさせたくないからで、selectの後に受信データより多いバッファ分読み込もうとしたらブロッキングしちゃうからノンブロッキングで読み込む方が良さそうな気がするけど何か見落としあったりします?
198デフォルトの名無しさん:2013/06/03(月) 01:24:07.02
> しちゃう

ダウト
199デフォルトの名無しさん:2013/06/03(月) 01:56:25.17
ブロックするだろ
200デフォルトの名無しさん:2013/06/03(月) 02:00:17.97
しないだろ
201デフォルトの名無しさん:2013/06/03(月) 02:05:28.99
>>199
しない
実験してみるといい
202デフォルトの名無しさん:2013/06/03(月) 02:05:39.31
うん。やっぱしないね>>199は忘れて
203デフォルトの名無しさん:2013/06/03(月) 03:59:52.42
1バイトでもデータがあればね
204デフォルトの名無しさん:2013/06/03(月) 11:23:03.45
selectした後の話だからね。>>197
205デフォルトの名無しさん:2013/06/03(月) 11:26:58.12
select後
受信データが1以上でバッファはデータ以上の大きさで読み込むと?
受信データが無いのに読み込むと?
206デフォルトの名無しさん:2013/06/03(月) 11:33:03.05
馬鹿じゃなかと?
207デフォルトの名無しさん:2013/06/03(月) 11:41:45.21
ゴカイうまかっちゃ
208デフォルトの名無しさん:2013/06/03(月) 12:12:09.02
むろみさんは海に還れ
209デフォルトの名無しさん:2013/06/03(月) 23:50:05.47
あんたドライバー刺すわよ
210192:2013/06/08(土) 23:51:12.09
かなり自己解決したっぽい
プロセスを起こすタイプのマルチスレッドサーバの現代版サンプル(他)↓
http://www.v6pc.jp/jp/upload/pdf/socket-sample-20121203.pdf
いとぢゅん氏が絡んでいたやつっぽいので多分信用に足る

で、Winsockにおいてプロセスにソケットを渡す方法↓
http://app.m-cocolog.jp/t/typecast/114340/102386/category/3335520
プロセスの終了を何の工夫も無くWaitForMultipreObjects()で待つと64プロセスが上限になるが、
そこはそれ、WaitForMultipreObjects()で64プロセス待つスレッドを64スレッド待つ、とかいう
多段構成が考えられる(いや知らんけど多分、

WinsockはGUIとの共存に適した非同期インタ──フェ──スも有するが、
とりあえずそこまでウィンドウズべったりにしなくとも、
select()かWsaPoll()だけでもマルチスレッドサ─バをなんとか構成できるのではないか(適当)
211192:2013/06/09(日) 00:01:04.61
ちなみに、WinsockではデフォルトでFD_SETSIZE=64だが、
socket()は平気でこれより大きいfd番号を返してくる

ていうか、現代のOSではLinuxだろうがWindowsだろうがFD_SETSIZEの制限に特に意味はなく、
FD_ISSET()の第一引数には 0..max{ socket()が返した値 } + 1 というの連番を与えるのではなくて、
socket()が返した数値(FD_SETSIZEより大きく成り得、かつ離散的)を配列かvectorにでもとっておいて、
その値を直接与えるのが正しいっぽい
上の現代版サンプルでもそうなっている(つまり>189のやり方は古い疑い有り)
212デフォルトの名無しさん:2013/06/09(日) 07:07:01.75
何言ってるか分からないが、その現代版サンプル(謎)でも fd + 1 になってるじゃねーか
213デフォルトの名無しさん:2013/06/09(日) 07:21:28.43
>>212
そこはそうだが、
http://x68000.q-e-d.net/~68user/net/c-echo-2.html
における
 166: for ( i=0 ; i<FD_SETSIZE ; i++ ){
 167: if ( FD_ISSET(i, &target_fds) ){
が、
http://www.v6pc.jp/jp/upload/pdf/socket-sample-20121203.pdf
の「複数の socket を生成するデュアルスタック対応サーバプログラム」では
 for (i = 0; i < smax; i++) {
  if (FD_ISSET(s[i], &rfd)) {
になってるねん(s[]にはsocket()が返した値が入っており、 smaxはs[]の要素数+1
214デフォルトの名無しさん:2013/06/09(日) 09:30:05.98
>>213
何を言いたいのか分からない

FD_SETSIZEを超えたらまずいというのならその通り。
下のURLの方は、

>> if (s[smax] >= FD_SETSIZE) {

でFD_SETSIZEを超えるものを除外してるから、
s[smax]がFD_SETSIZEを超えることはない

離散的だのベクターだのは意味不明
215デフォルトの名無しさん:2013/06/09(日) 13:20:01.15
>>214
話を込み入らせてしまって申し訳ないですが、
>> if (s[smax] >= FD_SETSIZE) {
これは少なくともWinsockでは不要ていうか、
>socket()は平気でこれ(FD_SETSIZE)より大きいfd番号を返してくる (211)
という事実があるので、削除して試した

実際、あるとgetaddrinfo()で列挙されたlisten可能ポート(うちの環境では
s[0] = 116, s[120]=120となった)が全てそのif文で除外され、
bind()やlisten()まで行き着かない。削除するとうまくいく(クライアントとつながり、"hello ::1"とか出る)

>FD_SETSIZEを超えたらまずいというのならその通り。
「何が」FD_SETSIZEを超えたらまずいのかいまいちどお考えいただきたい
FD_ISSET(a, b)の第一引数aが超えたらfd_set構造体をオーバーランするからまずい、というのが第一義だが、
しかし、>213の上のリンク先と、>213の下のリンク先では、第一引数に書かれている内容が異なるのですじゃ
216215:2013/06/09(日) 13:22:58.77
訂正。
誤1: getaddrinfo()で列挙されたlisten可能ポート
正1: getaddrinfo()で列挙されたlisten可能ソケット
誤2: s[0] = 116, s[120]=120となった
正2: s[0] = 116, s[1]=120となった
217214:2013/06/09(日) 17:26:56.22
一応「何が」について答えておくと、ファイルディスクリプタ番号。
fd_set構造体をオーバーランしたらまずい、という理解で合ってる。
>>213 の上の引用と下の引用の第一引数は同じなので、何言ってるかわからない。
218デフォルトの名無しさん:2013/06/09(日) 17:51:44.47
>>211
> socket()が返した数値(FD_SETSIZEより大きく成り得、かつ離散的)を配列かvectorにでもとっておいて、
> その値を直接与えるのが正しいっぽい
> 上の現代版サンプルでもそうなっている(つまり>189のやり方は古い疑い有り)

根本的に理解してないな。
>>189と同じ事を言っておいて、古い疑いありとはw
仕様と仕様を満たすための実装方法の区別がつかない人みたい。
実装方法で考えないと仕様が理解できない。
219デフォルトの名無しさん:2013/06/10(月) 11:24:49.53
私はselectは使わない、絶対に。
220デフォルトの名無しさん:2013/06/10(月) 11:30:49.49
絶対ニダ
221デフォルトの名無しさん:2013/06/15(土) 12:03:09.61
>>217>>218
はいはい御託は>189をWinsockで動かしてから言ってね&#9825;

BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無いから>189のコードで良い
0〜FD_SETまでの中に、必ずsocket()で作ったlisten中のソケットがある
Windsockでは違う
222デフォルトの名無しさん:2013/06/15(土) 15:40:20.49
>>221
> Windsock
ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?
つか,
> BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無い
保証は何処にある?
223デフォルトの名無しさん:2013/06/15(土) 15:58:13.05
FD_SETじゃなくてFD_SETSIZEの事言ってるんだろうけど
そんなもの使うのヤメレ
224デフォルトの名無しさん:2013/06/15(土) 15:59:06.31
保証されてるのはFD_SETSIZE未満の記述子に対してだな。
しれっとウソつくなよ。>>221
225デフォルトの名無しさん:2013/06/15(土) 16:46:01.43
>>222
> > Windsock
> ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?

違う。似て非なるもの。意味不明の改変もある。
226デフォルトの名無しさん:2013/06/15(土) 16:46:47.76
>>225
>>221は馬鹿でよく分かってないので間違ったこと書くのは仕方ない。
227デフォルトの名無しさん:2013/06/16(日) 12:00:56.26
windsockってなんだwinsock2のことかね
228デフォルトの名無しさん:2013/06/17(月) 12:46:20.67
>>227
1も2もどっちも嫌い
229デフォルトの名無しさん:2013/06/23(日) 03:27:09.95
別物なんだよなあ…ところどころ似てるけど全然違うから紛らわしい
230デフォルトの名無しさん:2013/07/03(水) NY:AN:NY.AN
質問です。
Winsockを使っています。
一度通信を終えた後に再度通信を行おうとすると、sendをacceptが認識してくれません。
bind,listen関数は正常に動作しています。
クライアント側は完全に再起動、サーバーはwhileで使いまわしています。
原因に心当たりのある人教えてください
231デフォルトの名無しさん:2013/07/03(水) NY:AN:NY.AN
>sendをacceptが認識してくれません

認識するわけなかろう
232230:2013/07/03(水) NY:AN:NY.AN
>>231
済みません。仰る通りでした。
connectの戻り値は0でクライアント側は繋がっていると認識しているようです。
サーバー側を消すとエラーが出てくるので間違い無いと思います。

サーバー側はacceptを使っているスレッドを消していない時は2つ以上の接続であっても、上手く動作します。
クライアント側が再接続する場合もちゃんと動きます。
しかしスレッドを再起動した時には一つ目の接続から認識しません。
変数は毎回初期化しています。
233デフォルトの名無しさん:2013/07/03(水) NY:AN:NY.AN
サーバーはwhileで使い回してるのにスレッドを再起動?
状況がよくわからんな
234デフォルトの名無しさん:2013/07/03(水) NY:AN:NY.AN
closeし忘れ?
235デフォルトの名無しさん:2013/07/03(水) NY:AN:NY.AN
>>232
ちゃんとListenしなおしてる?
236デフォルトの名無しさん:2013/07/04(木) NY:AN:NY.AN
listenしなおしってなんだよ
しっぱなしでいいだろ
いちいち再listenとかどこのBASICモドキだよ
237デフォルトの名無しさん:2013/07/04(木) NY:AN:NY.AN
accept に渡してるソケットを accept の戻り値で書き換えてるとか?

accept の戻りのソケットは 接続発生毎に別物だから
変な使いまわしからすると 「接続は受けた けど クライアントとの通信が出来てない」 ってなことになる
238230:2013/07/05(金) NY:AN:NY.AN
>>233,236
考えてみればlistenしっぱなしで良かったです;
設定を弄る時に排他処理が必要かと思い、止めようとしてました

>>234,5
再lisetn,closeはしていると思います。

>>237
有用な情報ありがとうございます!
以下のような処理をしてるので大丈夫だとは思いますが、調べてみます。

listen(--);
-初期化処理-
while(1){
dstSocket[id] = accept(----);
if(-1 != dstSocket[id]){
--------
id = DecideNewId();
}
}
239デフォルトの名無しさん:2013/07/09(火) NY:AN:NY.AN
これは肝心なところを隠して、どうでもいいところだけ書くダメな質問の典型だな
全体に意味不明だから、もう少し勉強してから出直すほうがいいと思う
240デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
ほとんどのバグは本人が関係ないと思って端折ってるところに存在する
そもそも肝心なところがどこか判ってるプログラマはむしろバグらない
241デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
なんでこうセンスの無い人間がプログラミングなんかやるのか
すべて駆逐したい
242デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
9割5分くらいのPGが消えてしまうじゃないか
243デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
104期生ってどのくらい巨人になれるの?
244デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
web(HTTP)の普及のせいで
ネットワークを利用するアプリの質が極端に下がった
退化しまくり
245デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
なんでもWebサービス。まあ便利だけどね。
246デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
webサービスは機種依存性をなくしたりアプリのインスコの手間を省いたりDLL地獄回避のメリットがあると言われていたが
結局ブラウザのバージョン依存で地獄とか同じ過ちを繰り返してるとしか
247デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
俺の言ったwebサービスはWebブラウザは関係ないけどね
248デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
P2P掲示板の同期方法はどうやればいいですか?
基本が一対一の通信なのに全体で同じデータを受け取れるのはむずかしくないですか?
249デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
通信速度が上がったから、HTTPのオーバーヘッドが気にならんからなぁ

>>248
P2Pで全体ってどういう事を言ってるのかしらんが
全体で同じデータを受け取る必要はないだろ
250デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
WebサービスってWSDLとかの話だろ、ブラウザ関係ねえw
251デフォルトの名無しさん:2013/07/10(水) NY:AN:NY.AN
ソケットでhttpクライアント作ってみたけど意外に簡単すね
でも企業面接でhttpの質問のみで落とされますた
252デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
java の質問で拾ってもらいました10年前
253デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
TCPのパケットの問題で落ちたわ…
254デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
>>248
難しくは無い。
全体に同じデータを送る必要があるなら、全体に同じデータを送るだけ。
非常に単純な話だよ。
255デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
実はUDPの方が転送効率は良いんです。TCPは糞です。
http://ascii.jp/elem/000/000/712/712158/
256デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
>>255
tcp6に採用されるような論文書かないと説得力全くない。
特殊な状況でしか効率良くないプロトコルじゃあ...
257デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
TCPが効率悪く見えるのは通信が1対1のときのを測定してるからだよな
多対多の通信を想定したプロトコルなんだから
258デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
TCPって思いっきり1対1の通信を想定したプロトコルじゃねーか。
259デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
故47氏がTCPを何十倍も超える高速通信を実現したとか聞いたが
260デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
TCPが回線スループットの何十分の1の速度しか出ないなんて事は無いから
言ってることが明らかにおかしい
261デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
UDPは一方向の無手順通信
無手順だから早いってだけでハマらんようにね
262デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
既存ファイル転送プロトコルに比べて大して変わらない性能で何のインパクトもなかった(当時)。
263デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
出たなMulticastTCPお化け!
264デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
SCTPのマルチホーミング構成をとっているときに
クライアント-プライマリサーバからはHEARTBEAT
の送信・応答があるんだけど、セカンダリサーバの
ほうってプライマリからのハートビートインフォメーションに
乗せるんじゃなくてセカンダリサーバからHEARTBEAT
返すことってSOCKOPTのパラメタ設定とかで可能?
265デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>260
複数セッション束ねるとか、方法はあるでしょ
266デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>260
TCPはRTT依存するし、パケットロスに対する速度低下率が高すぎる。
267デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>264
dynamic multihomingが有効なら管理されてるpathの死活を把握してないといけないから、
セカンダリでもheartbeatによるpath管理が行われているはず。
フリーの実装ならRandall Stewartさんが関わっていたFreeBSDが信頼性あるんじゃないか。

>>266
http://image.itmedia.co.jp/l/im/news/articles/1206/12/l_moto_ssbp.jpg
みると、最初からwindow最大化したTCP4とRTT性能は大差ないように思う。
ack管理が閾値ベースである問題は解消してるけど、
そんなのは10年以上前からあるし。
268デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
無罪判決後、47氏の夢   2012年  『Winnyの金子氏が夢見る次世代高速ネットの世界』
ascii.jp/elem/000/000/712/712158/
>金子:本当にTCPがボトルネックなんですよ。みなさんあまり気付いていないですけど、
>SilverBulletで動作させてみると楽勝で10倍くらいの通信速度が出るんですよ。ヘタすると100倍くらい出ますから。
269デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>258
多対多だおω
270デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>258はTCP層だけしか見てないから仕方ない
271デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
TCPコネクションが <自IPアドレス, 自ポート番号, 他IPアドレス, 他ポート番号>という
組(tupple)でモデル化されることは、このスレ住人にとっては常識だと思う。

で、TCP層の利用者(user)であるアプリケーションの視点からは、
TCPコネクションは相手アプリケーションとの間の「1対1」関係に見えるし、同時に
TCPコネクションの集合を扱うTCP層の提供者(provider)であるTCPスタックの視点からは、
自集合と多集合との間の「多対多」に見える。
272デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
ベストエフォート側のネットワークで、
みんな帯域を譲りあいながら使ってるわけだからさ、
じゃないとslow-startとか必要ないわけよ。
273デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>266
>パケットロスに対する速度低下
それは確かにそうだね
274デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
>>271
ふつう、全単射を「多対多」とは言わんわな。
275デフォルトの名無しさん:2013/07/12(金) NY:AN:NY.AN
言わないな
276デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
TCPを多対多とか言う奴はUMLの多重度も正しく書けないだろ
277デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
輻輳を意識したプロトコルなんだから
1対1のことだけ考えてる訳ではないよ
278デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
>>277
全くその通りだが、それは論点ではない
279デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
速度低下の原因が輻輳であるならば
1対1の場合なら速度低下は起きない
と言っているということになる
それではいったい47氏の主張と
どこが違うと言えると言うのか
280デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
何が言いたいのか伝わって来ない
281デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
流れぶった切って宣伝です
C++で通信ライブラリのようなものを作っております
よかったらお試しください
http://ichishino.nobody.jp/
282デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
>281
頑張ったところを教えて
283デフォルトの名無しさん:2013/07/13(土) NY:AN:NY.AN
どっかのTCP/IPスタックがお馬鹿ってだけじゃあ
284デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
>>281
これは酷い
某技術書のサンプルコードとほとんど同じコードばかりじゃねえかw
285デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
WinSockで通信プログラム作ってるんですけど
ポート1つで通信するとした場合
ホスト側でソケット2つ用意してクライアント2人と繋げたいんですけど
どうしても片方のソケットにしか二人分のデータが飛んでこないんですけど
どうしたらいいですかね
286デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
マヌケな発言はやめてくれ
力が抜ける
287デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
まず服を脱ぎます
288デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
このスレに来ていいレベルじゃないな
289デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
いつからこのスレがレベルの高いスレだったと錯覚している?
290デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
俺が来た時から
291デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
誰も高いなんて言ってないんだが...
292デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
>>289
安心しろ
君がいることがレベルが高くない証明だ
293デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
俺とお前と
294デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
田舎ではまだいるけど東京ではLooseSocksはほぼ絶滅したね。
295デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
>>294
へえ、じゃ今はどんなのがはやりなの?こっちは田舎(神戸)だからよくわからないや
296デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
いまはNoseFooksだな
297デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
自分からドナドナされにいくのか?
298デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
大五郎〜♪
299デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
おれとおまえと
300デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
だいごろお〜♪
301デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
>>282
ネットワーク通信ですかね
サーバーアプリつくれば3000コネクションぐらいだったらいけると思います
302デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
微妙だな。頑張ったと言うわりに10Kは特に意識してないってことか。
303デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
この業界は何かと3Kと言われますしね
304デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
>>302
テストは10Kでやってるんですが、まあユーザープログラムの実装を入れたらもっと下だろうってことで
305デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
長時間の安定稼働がきついんですよね
306デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
10Kコネクションで、最低でも一週間以上稼働し続けられるものを目指してはいます
307デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
で、それを実現するために何苦労したとか、
役立つことは一切語る気はない、ただの宣伝行為という認識でいい?
308285:2013/07/14(日) NY:AN:NY.AN
http://plsk.net/socket
マルチスレッドにしている部分のソースコードはらせて頂きました。
(現在は10個このスレッドを作成しています)
UDP/IPでの通信で同一ポートの使用が条件で
複数のクライアントと通信したいのですが
2箇所から通信してもらっても同じソケットにしかデータが着ません。
ここで質問なのですが
@分けることは可能なのでしょうか?(ソケットひとつにつき一人にする)
A分けない場合1つのソケットに複数のクライアントからデータが飛んできますが
 その様な動きはサーバーとしていいのでしょうか?
309デフォルトの名無しさん:2013/07/14(日) NY:AN:NY.AN
ソースは読んでないが、
同じソケットを使え
エラー処理はちゃんとやれ
310デフォルトの名無しさん:2013/07/15(月) NY:AN:NY.AN
>>308
不可能、いい

#ソースコードの断片から滲み出る初心者臭が酷いな
311デフォルトの名無しさん:2013/07/15(月) NY:AN:NY.AN
bindのエラーコードチェックすればすぐに分かることなのに
312285:2013/07/15(月) NY:AN:NY.AN
>>309
>>311
 書き直した所bindで最初以外の9つのソケットからエラーが出てました
 エラー処理は大事ですねありがとうございました

>>310
 1つのソケットでデータを受信することにします
 ありがとうございます
 C言語初めてもう5年近くなるのにひどいありさまです 
313デフォルトの名無しさん:2013/07/15(月) NY:AN:NY.AN
ソース読んでなかった人間だけど、
ちゃんと文章で説明できてたからエスパー出来た。
それほど酷い有様でもない。
314デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
特定のポートを使用しているプログラムを全員殺す
というプログラムはどうやって書けばいいかな
315デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
全員って?例えば?
316デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>315
たとえば、待ちうけや接続で ローカルポート9999 を使用している
プログラムを全員殺す

って fuser で一覧出して殺せばいいのか
ありがとう
317デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
全員って、一つのポートを複数のプログラムで使えたっけか?
318デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
使えますが?
319デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>318
どうやって使うの?
320デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
socket APIで。
TCPの接続は<src IP, src port, dst IP, dst port>の四つ組で識別される。
321デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>320
複数のプログラムで使えるのは、src portの方?dst portの方?
そのとき、send()やrecv()ってどうやるの?
322デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
特定のポートに接続してくる迷惑な相手鯖を全員殺す
というプログラムはどうやって書けばいいかな
(迷惑の基準は一秒間に一定回数回以上とかです)
ただフィルタするんじゃなくて相手側のプロセス(出来れば鯖ごと)殺したいです
323デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>321
あまりにも初歩的だからマニュアル嫁。
324デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
自分の管理下じゃない、相手プロセスを殺すのは無理

案1) IPメモって 上位のところに abuse 報告
案2) 接続ポートを特定化しないようにする細工がかけられればそれで自衛
325デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
IP特定できてるならダミー鯖を用意してそっちに誘導かなぁ
326デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>321
せっかく>>320がTCPコネクションの概念を明解に書いてくれているのだから、
その意味を(ネットの情報や書籍を参考にして)勉強してみたほうがいいと思うよ
327321:2013/08/05(月) NY:AN:NY.AN
今までいくつもソケットを使うアプリを作ってきたけど、同じポートを使うという
発想がなかったから全く想像つかないんです。
同じポート番号でlistenするってことなの?
328321:2013/08/05(月) NY:AN:NY.AN
あ、ひょっとして、connectで同じポート番号を使ったプロセスをkillしたいってことなのかな?
今使ってるポート番号じゃなくて。
329デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
何寝言いってるんだか
330デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
どんな糞アプリ作ってきたんだよ?
331デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
ポート80を使用しているプログラムを全員殺す=世界中のWebサーバを殺すってことだろ。
332デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
apache MPMを調べてみると良い。コードも読める。preforkが分かりやすい。
333デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
俺もソケットよくわかんね
教科書通りだとforkして平行宇宙せよってなってるし
実際試してもそれで同一ポートでの通信が出来ちゃうんだけど
四つ組じゃそれぞれのクライアントを識別するのはどうやってんだろうって
334デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
難しいことなど何もないよ
まずその教科書を投げ捨ててプログラミングしろ
335デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
シグナルとかが絡むとどうしたらいいかわからなくなる
例えばSIGPIPEが来たときreadしてるスレッドから来たreadの終了を表すものなのか
そのほかスレッドでの要因なのか判断する方法とかわからなすぎる
336デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>335
もしよければ教えるけど
337デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
WindowsSocketのGracefulShutdownを実装してSend側をshutdownしてから0が返るまでrecv呼ぼうとしたらそのままブロッキングしてcloseまで辿り着かないんですけど…
338デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>337
それほんとうにブロッキングしている?
ブロッキングと思い込んでるだけな気がする
339デフォルトの名無しさん:2013/09/02(月) 01:56:58.23
ASIOを使ってUDPでデータを送ってるんだが、遅延が酷い

すごく単純にするとこんな感じ
A→Bに一つの数値を送る
Bは他にいろいろやってるから処理は遅い

開始時のログ
A:1 2 3 4
B:1 2 3 4

しばらくすると、こうなる
A:123 124 125 126
B:98 99 100 101

時間が経てば経つほど、AとBの差が開いていく

内部バッファ?の古いパケットは捨てて、
最新のパケットだけ使う設定とかないのかな?
340デフォルトの名無しさん:2013/09/02(月) 02:33:02.02
>>339
録音再生なら、オーディオデバイスでのズレの蓄積が原因
341デフォルトの名無しさん:2013/09/02(月) 03:32:00.56
昔某メーカから調査頼まれたやつで、ドライバのクロック設定に
明らかなバグがあって、周波数が1%以上もズレてるのがあったよ
342デフォルトの名無しさん:2013/09/02(月) 03:39:03.02
そうじゃなくてもクロック偏差はどうしても存在するから
何らかの偏差吸収メカニズムがないと必ず破綻するよ
343デフォルトの名無しさん:2013/09/02(月) 07:25:01.12
ASIMOに運んでもらうか
344デフォルトの名無しさん:2013/09/02(月) 09:53:13.20
先行者で十分
345デフォルトの名無しさん:2013/09/17(火) 13:43:47.93
ユーザーの心拍数に同期するようにしたよ
346デフォルトの名無しさん:2013/09/17(火) 14:11:25.17
>>345
フィットネスの観点だと使い道あるぞw
347デフォルトの名無しさん:2013/09/17(火) 16:32:04.84
>>345
心拍数の測定に何使ってる?
348デフォルトの名無しさん:2013/09/17(火) 21:06:23.77
腕時計と人差し指・中指に決まってんだろ
349デフォルトの名無しさん:2013/09/17(火) 23:08:22.80
看護師が言ってたが、あまりあれは正確さが欠けるのでやりたくないらしい
350デフォルトの名無しさん:2013/09/18(水) 00:02:56.87
そういや最近bluetooth接続の心拍計があるな。ちょっと欲しい。けど一回しか使わなそう。
351デフォルトの名無しさん:2013/09/18(水) 02:25:41.95
SNMP TRAPあげてくれる体重計とか無いですかね。
いちいち倉庫から引っ張り出して乗るのは面倒なので椅子の下に常に敷いておくだけで40キロ以上の重量が加わったら時刻と重量を定期的に飛ばしてくれるだけでもだいぶ助かるんだけどなぁ。
352デフォルトの名無しさん:2013/09/18(水) 07:10:01.29
ときどき脈が飛ぶんだけど
こんな私でも通信出来ますか?
353デフォルトの名無しさん:2013/09/18(水) 07:48:21.31
めんどうだから
体重が2Kg以上増えたら電気ショックが流れるようにしたら
354デフォルトの名無しさん:2013/09/18(水) 14:45:09.07
> 体重が2Kg以上
この業界では2Kgなんぞは誤差のうちって奴がほとんどじゃないのか?
355デフォルトの名無しさん:2013/09/18(水) 22:32:36.64
>>354
一日で2Kg増えると考えると妥当と思うが
AIカーではシートが健康診断してくれるそうな(by TV)
356デフォルトの名無しさん:2013/09/18(水) 23:40:59.35
医師法違反ですね
357デフォルトの名無しさん:2013/09/19(木) 08:50:17.30
>>353
> 電気ショックが
この業界では電気ショックなんぞはご褒美のうちって奴がほとんどじゃないのか?
358デフォルトの名無しさん:2013/09/19(木) 15:50:42.93
こうしてショッカーが誕生した
359デフォルトの名無しさん:2013/09/19(木) 16:14:49.62
アイゴー
360デフォルトの名無しさん:2013/09/19(木) 16:18:53.73
ケー
361デフォルトの名無しさん:2013/09/20(金) 13:45:39.10
> 電気ショックなんぞはご褒美のうち
ラムちゃん (;´Д`)ハァハァ
362デフォルトの名無しさん:2013/09/21(土) 10:31:20.92
363デフォルトの名無しさん:2013/09/21(土) 10:47:02.53
宣伝乙
364デフォルトの名無しさん:2013/09/21(土) 16:49:30.81
>>362
これは面白そうなソフトだな
etherealと干渉しないなら使いたいな
365デフォルトの名無しさん:2013/09/21(土) 17:54:15.50
ホシュ
366デフォルトの名無しさん:2013/09/24(火) 03:26:25.19
>>352
俺もあるよ。徐脈性不整脈だろ。椅子の圧力でももの下側の血流が悪くなるのが原因だと俺は特定した。
デスクワークが多いPGの職業病ともいえる。びんぼうゆすりが有効。
367デフォルトの名無しさん:2013/09/24(火) 03:52:32.05
>>366
ありがとう
スタバの硬い椅子でも長居出来るように
座布団持ち歩いてるんだけどなぁ
368デフォルトの名無しさん:2013/09/24(火) 06:53:21.28
>>367
マーサージで血管を広げる、爪先立ちでかかとのあげさげ
だめなら病院行けよ(棒)
369デフォルトの名無しさん:2013/09/24(火) 08:21:30.10
社長椅子みたいのに変えれば治るの?
370デフォルトの名無しさん:2013/09/24(火) 08:29:35.42
ファーストクラス症候群
371デフォルトの名無しさん:2013/09/24(火) 09:06:17.61
>>367
長居するなよ迷惑なやつだなクソ野郎
372デフォルトの名無しさん:2013/09/24(火) 09:57:42.13
寝不足だろうな原因は
373デフォルトの名無しさん:2013/10/28(月) 21:37:00.93
ソケットで、すでに送信元ポートがbindしてあるかどうかって
なにで見るのが一番簡単かな
374デフォルトの名無しさん:2013/10/28(月) 22:10:23.60
netstat
375デフォルトの名無しさん:2013/10/29(火) 12:22:10.81
ニコニコ動画のコメントを取得するためにAPIを利用すればいいと思うのですが
それ以外に方法ありますか?
376デフォルトの名無しさん:2013/10/29(火) 13:55:49.85
selectで待つとき、
t.tv_sec = 0;
t.tv_usec = 0;
で無限に待つかと思ったらすぐ帰ってくるのな
これ無限に待ちたいときは何セットすんだっけか
377デフォルトの名無しさん:2013/10/29(火) 14:06:06.03
>>376
nullだよ
378デフォルトの名無しさん:2013/10/29(火) 16:09:23.36
>>377
おおーありがとう
379デフォルトの名無しさん:2013/10/30(水) 10:04:00.99
中国から輸入したアイロンに無線LAN経由でスパム攻撃をするチップが発見される
http://gigazine.net/news/20131029-spam-chips-hidden-in-iron/

PCだけ気を付けてもダメだったな
380デフォルトの名無しさん:2013/10/30(水) 19:48:01.50
>>379
アイロンってシワを伸ばすアレだよね。
無線LANに自分で接続しない限り、認証が必要なんだし気をつける必要はないでしょう。
どちらかと言うと、干渉によるノイズが気になる。
381デフォルトの名無しさん:2013/10/31(木) 09:52:44.31
近所でパスワードなしの野良APがあったら終わりw
382デフォルトの名無しさん:2013/10/31(木) 10:34:48.52
あるよな
いがいと
たくさん
383デフォルトの名無しさん:2013/10/31(木) 12:00:45.17
「一番つながりやすい会社」のだろう
384デフォルトの名無しさん:2013/10/31(木) 13:32:30.12
やわらか銀行
385デフォルトの名無しさん:2013/11/19(火) 01:28:55.04
プログラムからICMP(v6) echo requestを送る必要が出て来て、送り先を探しています。

1 ipv4とipv6のアドレスを持っている
2 実際には届かなくてもok
3 経路上のルータからunreachが返って来てもok
4 突然dnsレコードが亡くなったりしない
を満たすホストは有りますか?
m.root-servers.netがこれに該当しますが、他にありますか?

送る理由は企業秘密です
頻度は最大1パケット/1分
386デフォルトの名無しさん:2013/11/19(火) 08:02:07.09
MSがインターネット接続の確認用に立ち上げてるdns.msftncsi.comを使う事にしました
387デフォルトの名無しさん:2013/11/19(火) 08:35:42.45
>>385
迷惑行為
388デフォルトの名無しさん:2013/11/19(火) 08:40:53.32
>>385
キチガイ死ね
389デフォルトの名無しさん:2013/11/19(火) 09:45:08.25
MSがネットワーク接続の確認にwww.msftncsi.comからダウンロードするのは
キチガイじゃないんですか?

https://sect.iij.ad.jp/d/2012/08/109998.html
によるとベストアワードを受賞した論文は、無断でsshポートから
サーバー公開鍵を収集したみたいだけど、これは許されるの?
390デフォルトの名無しさん:2013/11/19(火) 09:48:26.01
自分の持ち物の回線・サーバを使って何が悪い。
公開されている鍵を集めて何が悪い。

お前のは他人の回線・サーバを悪用する犯罪行為。
391デフォルトの名無しさん:2013/11/19(火) 09:50:48.03
途中の回線は他人の物だ
392デフォルトの名無しさん:2013/11/19(火) 09:51:36.07
真正のキチガイなんだな、あーやだやだ
死んでくれないかな
393デフォルトの名無しさん:2013/11/19(火) 09:52:21.17
>>391
そう思うなら、いますぐプロバイダ解約したまえ
394デフォルトの名無しさん:2013/11/19(火) 09:53:32.21
>>391
インターネット批判とか、おまえどんだけ偉いの?
395デフォルトの名無しさん:2013/11/19(火) 09:54:46.31
他人のサーバーをpingで攻撃してはいけません
って言われないと、攻撃してもいい、と判断するのがゆとり世代。
396デフォルトの名無しさん:2013/11/19(火) 09:57:11.55
経路を自社の製品のために利用するのは許されるという主張か?

ターゲットホストに届かなきゃいいって事だな
TTL 1にするからこれなら文句ないだろ
397デフォルトの名無しさん:2013/11/19(火) 09:57:58.97
m.root-servers.netを襲うかもしれないし、
通報しておいたほうがいいんじゃね?
こういう不文律が通じないアフォは徹底的に駆除するべき
398デフォルトの名無しさん:2013/11/19(火) 09:59:58.85
ping禁止が不文律? www
399デフォルトの名無しさん:2013/11/19(火) 10:02:46.47
>>397
m.root-servers.netはWIDEが運用してるから、WIDEに「ping攻撃企んでるアホがいる」と通報してくれ。
通報結果も教えてね。 はーと
400デフォルトの名無しさん:2013/11/19(火) 10:06:46.11
何かいけないことなのかすら理解できていないんだな。
401デフォルトの名無しさん:2013/11/19(火) 10:08:41.95
アホ 通報する方が迷惑行為だわ
とっとと、通報しろよ
402デフォルトの名無しさん:2013/11/19(火) 10:11:51.74
ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
論理的に説明してみろ 出来なきゃお前の負けな
403デフォルトの名無しさん:2013/11/19(火) 10:13:38.09
1ping/min位なら普通に自分のプロバイダのDNSにpingすりゃいいんじゃねーの?
なんでわざわざrootサーバー使うんだ
404デフォルトの名無しさん:2013/11/19(火) 10:14:23.94
後出しでttl 1になりました!
ttl 1入りまーす!www
405デフォルトの名無しさん:2013/11/19(火) 10:17:22.97
>>403
プロバイダに依存したくないからに決まっているだろアフォか
406デフォルトの名無しさん:2013/11/19(火) 10:18:45.47
他の方法を取るべき事の代替にping使おうとしてねえか?
407デフォルトの名無しさん:2013/11/19(火) 10:18:52.81
>>404
こういうことをするときの不文律だろttl 1は
はじめからそのつもりだったにきまってるだろ
言われるまで気づかなかった奴はネット使う資格はない
408デフォルトの名無しさん:2013/11/19(火) 10:20:24.82
>>405
一言でもそういったのか?
なら決まってないと思うが
409デフォルトの名無しさん:2013/11/19(火) 10:20:41.10
>>406
企業秘密を聞き出そうとしても無駄
姑息な工作をしている暇があるなら>>402に答えろ
410デフォルトの名無しさん:2013/11/19(火) 10:22:43.01
>>408
不文律だろ不文律
わかんない無能は氏ね
411デフォルトの名無しさん:2013/11/19(火) 10:26:18.07
>>406
目的は企業秘密 実現手段として選んだのがICMP echo requestを投げる事
他の手段の存在は否定できないが、アホが集まる2chで質問する事ではない
412デフォルトの名無しさん:2013/11/19(火) 10:26:23.01
他所のNSに負荷かけんなよ
413デフォルトの名無しさん:2013/11/19(火) 10:28:10.07
>>410
!!!!ttl = 1でもICMP echo requestを無差別に投げる事は禁止!!!!
そんな不文律ねーよ wwww

お前の負け 引っ込んでろよ
414デフォルトの名無しさん:2013/11/19(火) 10:30:23.54
>>412
今度はNSか wwww
ISPのNSは使い放題という事で契約している

お前の負け 引っ込んでろ
415デフォルトの名無しさん:2013/11/19(火) 10:31:59.97
DNSの仕組みも知らないのか。
416デフォルトの名無しさん:2013/11/19(火) 10:34:38.18
なにやりたいんだか知らないけど、
常識的には、ネームサーバもEcho受けるサーバも自前で設置するものだよ。
他人の資源を勝手に転用しちゃいけない。
417デフォルトの名無しさん:2013/11/19(火) 10:34:39.63
釣り名目でひたすら他人を罵倒したいだけのガキだな

TTL1ならどこ指定してもゲートウェイか近くで止まるんだから
固定する必要すらない
事前の想定をきちんと理解してるなら質問の意味ないだろ
知能指数測ってこい池沼
418デフォルトの名無しさん:2013/11/19(火) 10:39:54.83
>>416-417
アホが必死で喚いても

> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
これを説明できない お前の負け
419デフォルトの名無しさん:2013/11/19(火) 10:41:05.34
やりたいことが、経路があるか知りたいとか、アドレスがあるか知りたい、
なのに対して、実現手段として基本的なソケットインタフェースしか知らない
無恥野郎なんだろうな
420デフォルトの名無しさん:2013/11/19(火) 10:42:01.13
>>419
アホが必死で喚いても

> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
これを説明できない お前の負け
421デフォルトの名無しさん:2013/11/19(火) 10:43:45.98
企業の防壁によっては、管理者にアラートがあがるよ<ttl=1
422デフォルトの名無しさん:2013/11/19(火) 10:45:47.42
blacklistに登録されてbangされるようになるとかそういう方向で解決されるんじゃね
423デフォルトの名無しさん:2013/11/19(火) 10:47:52.46
IPv6はそもそもTTLじゃないという突っ込みはなし?
424デフォルトの名無しさん:2013/11/19(火) 10:48:16.40
>>421
必死すぎる www
そこではtraceroute禁止ですかあ?

>>422
パケットが出ていかないのにブラックリストに登録とか 必死すぎる www

お前の負け
425デフォルトの名無しさん:2013/11/19(火) 10:51:21.74
>>424
企業ネットワークでtracerouteを打つとか、普通に懲戒処分のところもある
無知すぎるぞおまえ
426デフォルトの名無しさん:2013/11/19(火) 10:55:03.73
wiresharkやtcpdumpなどpromiscasモードアプリ=即検出、一発解雇
とかはよく聞く。
427デフォルトの名無しさん:2013/11/19(火) 11:01:18.87
許可された特定のアプリ以外は使用禁止の企業もあるだろうが、
そういうところじゃないから作ってるし、そういうところでは使われない。

必死でひねり出した反論もアホの極致
惨めすぎるぞお前
428デフォルトの名無しさん:2013/11/19(火) 11:00:51.38
そういえば10年くらい前にバカhub挿して端末増やしたら怒られたことあったわ
429デフォルトの名無しさん:2013/11/19(火) 11:04:59.19
今時tcpdumpで盗聴なんてできないのに老害adminは死ねって感じ
430デフォルトの名無しさん:2013/11/19(火) 11:05:13.24
最近の企業コンプライアンスは異常だからなぁ。
traceroute禁止とか聞いても、そうなんだくらいにしか思わん。
勝手にネットワーク障害を解決して解雇とかという話も事例として
よく出てくるしな。
431デフォルトの名無しさん:2013/11/19(火) 11:06:28.60
>>429
arp spoofingなんていまでも有効で無防備だから仕方がない。
432デフォルトの名無しさん:2013/11/19(火) 11:10:05.05
>>431
ARPエントリの変更はそれこそ監視対象 お前ズレてる
433デフォルトの名無しさん:2013/11/19(火) 11:11:57.55
m.root-servers.netに通報と騒いでたバカは逃亡したか?
通報結果を知りたいのだが
434デフォルトの名無しさん:2013/11/19(火) 11:13:05.65
>>432
ノート型全盛で端末のネットワーク位置がどんどん変わるから
いまはまたarp spoofingに対応できない時代になっているんだよ。
435デフォルトの名無しさん:2013/11/19(火) 11:18:42.23
ARPエントリが20分有効ってのがそもそもおかしいんだよな。
やりたい放題。
436デフォルトの名無しさん:2013/11/19(火) 11:23:03.21
>>434
ステーション間の通信は遮断だろ 普通
そんな事も出来ないadminなら解任した方が良い
437デフォルトの名無しさん:2013/11/19(火) 11:55:39.23
>>433
何一人で顔真っ赤にして盛り上がってんの?
いい加減空気読めよ
438デフォルトの名無しさん:2013/11/19(火) 12:04:05.97
>>437
通報してから出直しな
アホ
439デフォルトの名無しさん:2013/11/19(火) 12:58:57.56
かいじせいきゅう
440デフォルトの名無しさん:2013/11/19(火) 13:26:27.58
pingが攻撃
三菱電機インフォメーションシステムズの最底辺SEですら言わねーぞ
441デフォルトの名無しさん:2013/11/19(火) 13:30:16.32
固有名詞出してんじゃねーよ非常識オレサマ野郎
442デフォルトの名無しさん:2013/11/19(火) 13:42:27.40
年末特番「はじめてのつうほう」
撮影快調! 乞うご期待!
443デフォルトの名無しさん:2013/11/19(火) 13:44:50.26
いやまあ三菱電機インフォメーションシステムズのやったことは犯罪に近いですしおすし知らないならググレカス
444デフォルトの名無しさん:2013/11/19(火) 14:03:01.50
>>443
ぐぐっても何も出てきませんよ
445デフォルトの名無しさん:2013/11/19(火) 14:06:14.25
>>441
三菱電機インフォメーションシステムズの関係者?
あんなド底辺と関係あるって恥ずかしくない?

だからpingで通報とか言っちゃうのか
446デフォルトの名無しさん:2013/11/19(火) 14:06:42.18
2ch来るような奴が知らないわけねえだろ
いちいち見下す発言しかできねーのか屑
447デフォルトの名無しさん:2013/11/19(火) 14:07:25.30
>>444
岡崎図書館事件を知らないドドド底辺がいるとわ
448デフォルトの名無しさん:2013/11/19(火) 14:08:50.33
>>446
見下されたくなかったら、ド底辺な発言しないことだ

ping攻撃!!! 通報すべき!!!
449デフォルトの名無しさん:2013/11/19(火) 14:09:00.20
で、TTL1のpingで何がしたかったのコミュ障
450デフォルトの名無しさん:2013/11/19(火) 14:10:18.31
>>448
本気で同一人物だと思ってるの?呆れるわ
一人で盛り上がりすぎなんだよオナニー野郎
451デフォルトの名無しさん:2013/11/19(火) 14:14:28.50
>>449
NDAで教えてやろうか?
公的個人認証で署名した秘密保持契約書アップしたら教えてやるよ

>>450
そういう事にしたいならしといてやるよ
452デフォルトの名無しさん:2013/11/19(火) 14:18:33.48
>>451
NDAとか何背伸びしちゃってんの?ウケルー
453デフォルトの名無しさん:2013/11/19(火) 14:18:58.40
つか、
>>385
> m.root-servers.netがこれに該当しますが、他にありますか?

他に探す理由は?
454デフォルトの名無しさん:2013/11/19(火) 14:27:28.35
1 引けない場合に備える
2 選択肢は多い方が良い
455デフォルトの名無しさん:2013/11/19(火) 14:29:14.94
aでもbでもcでも好きなの使え
456デフォルトの名無しさん:2013/11/19(火) 14:30:08.16
他のルートサーバー使えばいいだけじゃん
457デフォルトの名無しさん:2013/11/19(火) 14:31:54.89
8.8.8.8でいいんじゃないの?
458デフォルトの名無しさん:2013/11/19(火) 14:58:26.43
>>385
企業ならいくつかのデータセンターにラック借りてるだろう
どれか適当な自社サーバー相手にping打てよ
459デフォルトの名無しさん:2013/11/19(火) 15:00:52.23
ipv6.msftncsi.comってのがあった、v6はこっちにしよう
460デフォルトの名無しさん:2013/11/19(火) 15:10:36.87
もう解決したんだから、後はブログでお願い。
461デフォルトの名無しさん:2013/11/19(火) 15:18:32.58
もりあがってると思ったら、あらされてるのか
逆切れ--->あらしのパターンか
462デフォルトの名無しさん:2013/11/19(火) 15:40:15.95
>>459
自社サーバー使えよ
463デフォルトの名無しさん:2013/11/19(火) 16:14:19.64
>>462
これ説明してよ

> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
464デフォルトの名無しさん:2013/11/19(火) 16:17:37.16
いい加減、別板か過疎スレでsage進行でやってくれ。
465デフォルトの名無しさん:2013/11/19(火) 16:46:59.97
>>463
無差別じゃなくて、一点集中攻撃だよな
466デフォルトの名無しさん:2013/11/19(火) 16:51:48.28
無差別に投げられるレス
467デフォルトの名無しさん:2013/11/19(火) 17:16:02.58
ttlがなんだかわかってないやつが混ざっててわかりにくいぞ、進行が。
468デフォルトの名無しさん:2013/11/19(火) 17:16:12.77
>>385はびっぷ板からきたのか
469デフォルトの名無しさん:2013/11/19(火) 17:21:12.38
> ティーティーエル
> TTL 【 Time To Live 】
>
> パケットの有効期間を表す値。最大255までの整数値で表され、ルータなどを1回経由されるたびに値が1減少する。
> TTLが0になったパケットはその時点で廃棄され、廃棄通知がパケットの送信元に届くようになっている。

へー、はじめて知ったわ。
470デフォルトの名無しさん:2013/11/19(火) 17:23:37.31
繰り返しになってきたな アホの相手も飽きたので

この説明
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか

または
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
これの通報結果以外はレスすんな アホども

あと、三菱電機インフォメーションシステムズのド底辺SEなら上記に関わらずレスしていいよ。
471デフォルトの名無しさん:2013/11/19(火) 17:29:01.01
>>470
だから、aでもbでもcでも好きなの使えって
それ以上に何求めてんだよ
472デフォルトの名無しさん:2013/11/19(火) 17:34:22.36
>>471
もうそれは終了してるから。www.msftncsi.com, ipv6.msftncsi.com
あとbはダメ 知ったかすんなよ

> それ以上に何求めてんだよ
↓かな 笑い

この説明
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか

これの通報結果
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
473デフォルトの名無しさん:2013/11/19(火) 17:35:09.14
うざ
474デフォルトの名無しさん:2013/11/19(火) 17:37:16.04
>>472
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
いけなかない

> これの通報結果
多分通報した奴なんかいない
475デフォルトの名無しさん:2013/11/19(火) 17:44:21.27
>>472
すきにしろ
476デフォルトの名無しさん:2013/11/19(火) 17:46:34.42
NDSがらみのことを2ちゃんねるで聞くとはぷげらちょ
477デフォルトの名無しさん:2013/11/19(火) 17:48:18.64
>>472
いい加減消えてくれ
478デフォルトの名無しさん:2013/11/19(火) 18:19:01.84
>>475-477
お前ら、三菱電機インフォメーションシステムズのド底辺SEは生きてて恥ずかしくない?
479デフォルトの名無しさん:2013/11/19(火) 20:11:44.12
きいてるきいてる
480デフォルトの名無しさん:2013/11/20(水) 00:16:31.65
暴れるなら酉出せよチンカスども
481デフォルトの名無しさん:2013/11/20(水) 10:43:54.01
iptables で許可されたパケットだけをダンプするコマンドはありますか?
tcpdump だと全部のパケットが出て来てしまいます ><
482デフォルトの名無しさん:2013/11/20(水) 11:19:37.38
tcpdumpは懲戒だと、三菱インフォメーションシステムズのド底辺SEが言ってた
483481:2013/11/20(水) 13:24:59.68
僕が懲戒になっても後に続く若人たちの踏み台になれるなら本望です
おしえてください!!!
484デフォルトの名無しさん:2013/11/20(水) 13:35:07.54
iptables と同じようになるようにオプションではじいたら
485デフォルトの名無しさん:2013/11/20(水) 14:10:07.18
>>481
tcpdumpはフィルターの指定ができるだろう
486デフォルトの名無しさん:2013/11/20(水) 14:20:09.07
まだいたのか・・本物だなこりゃ
487デフォルトの名無しさん:2013/11/20(水) 15:59:15.44
こんなド底辺に出くわすなんて、1年に1回あるかないかだからね
早く通報してくれよ

> m.root-servers.netを襲うかもしれないし、
通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
488デフォルトの名無しさん:2013/11/20(水) 16:11:11.80
>>487
お前がTTL 1だとあかしたレスを読む前にレスしたんだろうよ。

> 396 名前:デフォルトの名無しさん[] 投稿日:2013/11/19(火) 09:57:11.55 <- 秘密の暴露レス
> 397 名前:デフォルトの名無しさん[sage] 投稿日:2013/11/19(火) 09:57:58.97 <- 通報するぞレス
489デフォルトの名無しさん:2013/11/20(水) 16:21:13.83
>>487
お前みたいなアホに出くわすのも、1年に1回あるかないかだわ
490デフォルトの名無しさん:2013/11/20(水) 16:41:07.53
>>478
カジュアルにこんな毒吐いてると、いつか足下すくわれるぞ。
491デフォルトの名無しさん:2013/11/20(水) 16:58:24.67
>>488
見てない証拠はねーし、pingを最大1パケット/1分は最初から言っていた
これでもいいから早く通報しろ

>>490
三菱インフォメーションシステムズはそれだけの事したんだから良いんだよ
むしろ風化させないために煽り続けるべき
492デフォルトの名無しさん:2013/11/20(水) 17:10:04.64
相手するから居座るんだよ。
完全無視しろ。
493デフォルトの名無しさん:2013/11/20(水) 17:22:39.21
この手のは嫌なら見るなするくせに、
トリップ付けろって言っても絶対付けないよな。
494デフォルトの名無しさん:2013/11/20(水) 17:37:49.41
いや、こんなド底辺めったに遭遇できない
がんばってageるのであぼーんしないでみんな見てほしい

ttl = 1のpingを最大 1 パケット/1分で通報すべしとのたまう
ド底辺の醜態をお楽しみください

http://toro.2ch.net/test/read.cgi/tech/1351670708/397
> From: [397] デフォルトの名無しさん <sage>
> Date: 2013/11/19(火) 09:57:58.97
>
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
495デフォルトの名無しさん:2013/11/20(水) 17:40:22.31
>>484-485
ありがとう
-F オプションは判ったけど
iptables と書き方が違うので
ルールが沢山あって変換が面倒です ><
496デフォルトの名無しさん:2013/11/20(水) 17:45:17.11
iptablesにログ機能くらいあるだろ、それ使えよ ド底辺
497デフォルトの名無しさん:2013/11/20(水) 17:54:20.35
検索すりゃ簡単に出てくるじゃねーか ド底辺
http://sgros-students.blogspot.jp/2013/05/debugging-iptables-rules-with-tcpdump.html
498デフォルトの名無しさん:2013/11/20(水) 18:24:25.55
10分間に1000回アクセスすると逮捕されるというのは、韓国のF5攻撃から
2CHを守るためにできた法律だろ?
499デフォルトの名無しさん:2013/11/20(水) 18:27:33.77
百度とNAVERから俺のサーバを守るための法律。
500デフォルトの名無しさん:2013/11/20(水) 18:44:29.00
httpの場合は三菱インフォメーションシステムズのド底辺SEの
策謀が功を制して1リクエスト/1秒で逮捕という事になっている
10分なら600リクエストで逮捕

HTTPよりも遥かに低負荷(しかもttl = 1 爆笑)のpingを10リクエスト/10分で
攻撃だ!! 通報だ!!! 駆除だ!!!!

めったに遭遇できないド底辺
501デフォルトの名無しさん:2013/11/20(水) 19:36:11.08
この粘着力
他でも荒らしてそうだな
502デフォルトの名無しさん:2013/11/20(水) 19:41:27.97
>>497
thx!!
503デフォルトの名無しさん:2013/11/20(水) 19:42:10.19
ド底辺が発言どおりに通報して通報結果を報告すりゃ終了するんだが

言ったことは実行しろよ
504デフォルトの名無しさん:2013/11/20(水) 19:45:17.47
俺俺プロトコルは通報パケットが発行されるまで終了せずリソースも開放しないと定義されております
505デフォルトの名無しさん:2013/11/20(水) 20:10:43.02
恥かかせたいってことなら、
自分で通報して結果貼ればいいんじゃないの。
とにかく続けたいにしても別板でスレ立ててそこでやってくれ。
506デフォルトの名無しさん:2013/11/20(水) 20:22:58.19
くやしいのうwくやしいのうw
507デフォルトの名無しさん:2013/11/20(水) 20:25:53.27
>>397みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが

> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
508デフォルトの名無しさん:2013/11/20(水) 20:26:59.21
くやしいのうwくやしいのうw
509デフォルトの名無しさん:2013/11/20(水) 20:29:10.20
酉付けろよキチガイ
510デフォルトの名無しさん:2013/11/20(水) 20:29:46.25
m.root-servers.netを目的外に使うって言いだした時点で
完全敗北しているのに、いまだ生き恥をさらしているのかw
くやしいのうwくやしいのうw
511デフォルトの名無しさん:2013/11/20(水) 20:31:53.74
何がそんなに悔しかったんだろう?
最初からttl=1って書いておけば、こんなにもバカにされなかったネタだと思うんだがな。
512デフォルトの名無しさん:2013/11/20(水) 20:32:58.04
くやしいのうwくやしいのうw
513デフォルトの名無しさん:2013/11/20(水) 20:36:15.60
>>510
完全敗北という妄想はお前の半径3m以内でしか通じない不文律の話だろ。
514デフォルトの名無しさん:2013/11/20(水) 20:37:30.44
くやしいのうwくやしいのうw
515デフォルトの名無しさん:2013/11/20(水) 20:39:01.58
>>510
なんで?
公開サーバーなんだからping打つくらい問題ないでしょ。
いやなら公開するなよって話だ。
516デフォルトの名無しさん:2013/11/20(水) 20:53:39.59
ttl=1で、最初から届かないことが確定でいいなら、
そもそも宛先はルートサーバーではなくてランダムアドレスでいい
517デフォルトの名無しさん:2013/11/20(水) 20:56:05.91
他の人が同じことを始めたらどうなってしまうか、
考えられないのが山本太郎
518デフォルトの名無しさん:2013/11/20(水) 20:57:34.97
>>510
ほれ、とっとと通報しろよ ド底辺
519デフォルトの名無しさん:2013/11/20(水) 20:59:32.82
>>516
だったらデフォルトルートがあるかどうかを見るだけでよくて
ttl=1以前にパケット送る必要自体がなくね?
520デフォルトの名無しさん:2013/11/20(水) 21:00:18.41
くやしいのうwくやしいのうw
521デフォルトの名無しさん:2013/11/20(水) 21:01:07.93
>>517
ttl = 1のpingを10万人位がm.root-servers.netに向けて一斉に打ちまくると、
どこにどんな影響があるのか説明してみろ ド底辺
522デフォルトの名無しさん:2013/11/20(水) 21:02:59.85
くやしいのうwくやしいのうw
523デフォルトの名無しさん:2013/11/20(水) 21:16:28.30
>>515
死ねよ人間のクズ
524デフォルトの名無しさん:2013/11/20(水) 21:19:41.52
なんでまだroot-serversに拘ってるの
ttl=1なんだから関係ないじゃん
説明してみてよ
525デフォルトの名無しさん:2013/11/20(水) 21:24:11.51
>>524
NDAで説明してやるよ
公的認証で署名した誓約書何処かにうpしな
526デフォルトの名無しさん:2013/11/20(水) 21:24:28.21
>>524
馬鹿は引っ込んでろ
527デフォルトの名無しさん:2013/11/20(水) 21:26:14.11
>>525
いくら自分が理解できないことだからって
そういう言い訳しちゃ駄目だよ
528デフォルトの名無しさん:2013/11/20(水) 21:30:12.24
>>524
ちなみに、root-serversじゃなくてMSのサーバーを使う事にした
m.root-serversはド底辺が日本語で通報できるように、バックアップとして使用する事にしている
早く通報しろ ド底辺

>>527
最初から目的は企業秘密と断ってある
知りたいなら誓約書だせよ
529デフォルトの名無しさん:2013/11/20(水) 21:30:30.67
同一ネットワークでそのプログラム使っているホストが沢山いたら、そこのデフォルトゲートウェイの負荷が増えるし、そういうアプリが沢山あったら、ホスト自身の負荷も増えるな。
アプリの目的にもよるが、マルウェア扱いされそうだ。
530デフォルトの名無しさん:2013/11/20(水) 21:32:08.50
>>528
わからないならわからないってえ言えばいいのに
きちんとTTLの意味から教えてあげるよ?
531デフォルトの名無しさん:2013/11/20(水) 21:32:11.21
くやしいのうwくやしいのうw
532デフォルトの名無しさん:2013/11/20(水) 21:32:54.87
恥ずかしくて言えない企業秘密もあるさ
533デフォルトの名無しさん:2013/11/20(水) 21:35:58.16
>>529
負荷見積もりも出来ない ド底辺
534デフォルトの名無しさん:2013/11/20(水) 21:38:46.51
>>530
わかりませーん

ttl = 1のpingを10万人位がm.root-servers.netに向けて一斉に打ちまくると、
どこにどんな影響があるのか説明してくださーい
535デフォルトの名無しさん:2013/11/20(水) 21:42:58.55
くやしいのうwくやしいのうw
536デフォルトの名無しさん:2013/11/20(水) 21:44:25.03
>>534
またそうやって話をずらすんだから
よくわかってないから固定にしなきゃいけないと思ってるんでしょ?
言ってごらん?わからない部分があるなら説明してあげるからさ
537デフォルトの名無しさん:2013/11/20(水) 21:50:57.43
そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
HopLimitとは違うのだよ。
538デフォルトの名無しさん:2013/11/20(水) 21:52:28.05
>>536
煽って聞き出そうなんて、20世紀に流行ったおじいちゃんの手法

固定としか考えつかないの? 頭悪すぎる
539デフォルトの名無しさん:2013/11/20(水) 21:56:02.80
>>385
>1 ipv4とipv6のアドレスを持っている
>2 実際には届かなくてもok
>3 経路上のルータからunreachが返って来てもok
>4 突然dnsレコードが亡くなったりしない

Time Exceededが返って来てもok
って書いてないからttl=1はダメだよね
自分で出した条件から外れてるよ
540デフォルトの名無しさん:2013/11/20(水) 22:16:18.35
>>537
知らないなら引っ込んでなよ
541デフォルトの名無しさん:2013/11/20(水) 22:18:31.60
>>540
じゃあどこに書いてあるんですか?
542デフォルトの名無しさん:2013/11/20(水) 22:27:21.19
>>541
なんで決まりが無いと思ったんだい?
543デフォルトの名無しさん:2013/11/20(水) 22:29:19.09
>>542
あるなら早く出してね。
簡単でしょ?公式な文書から1文見つけるだけなのだから。
544デフォルトの名無しさん:2013/11/20(水) 22:32:00.74
というより「決まりがある」と思っているそのこと自体が、
TTLをまったく理解していない何よりの証拠なんだけどね。
なぜ「Time」To Liveなのか。なぜIPv6でHopLimitに取って代わられたのか。
この業界の人間なら知らないはずはないんだけどねぇ。
ああ。恥ずかしい恥ずかしい。
545デフォルトの名無しさん:2013/11/20(水) 22:34:47.74
本当にド底辺なんだな 英語読める? 訳してとかいうなよ

http://tools.ietf.org/html/rfc791
The time is measured in units of seconds, but since every module
that processes a datagram must decrease the TTL by at least
one even if it process the datagram in less than a second,
the TTL must be thought of only as an upper bound on the time
a datagram may exist.
546デフォルトの名無しさん:2013/11/20(水) 22:37:24.17
自分で持ってきた英文をよく読んでごらん。
英語理解できないの?
547デフォルトの名無しさん:2013/11/20(水) 22:39:56.86
せっかく貼ってやったんだから英文をよく読んでごらん。
英語理解できないの?
548デフォルトの名無しさん:2013/11/20(水) 22:41:46.37
ド底辺 vs パシリ
549デフォルトの名無しさん:2013/11/20(水) 22:42:48.64
このバカはどう読んで
> そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
という理解に達したんだろう? 謎だ 謎すぎる

貼ってあげた英文翻訳してみてよ
550デフォルトの名無しさん:2013/11/20(水) 22:44:23.30
翻訳してよ。英語理解できないんだからさw
よろしくたのまー。
551デフォルトの名無しさん:2013/11/20(水) 22:45:31.86
まさか、「1じゃなくて2引く可能性も3引く可能性もある」とか小学生みたいな事言い出すのかな?
552デフォルトの名無しさん:2013/11/20(水) 22:52:06.98
やっぱり英文が理解できないようだね。
読めればすぐにわかるのに。
553デフォルトの名無しさん:2013/11/20(水) 22:55:27.20
コイツちょっとからかっただけで勝手にファビョってage連投するなw
最高オモチャw
554デフォルトの名無しさん:2013/11/20(水) 22:55:35.94
RFCはRequest For Commentであって規格書ではないから
従う決まりはないとか。
555デフォルトの名無しさん:2013/11/20(水) 23:00:51.89
>>521
そういうのが流行ると、ttlを変えずにルートサーバーにping打ち続ける人が増える要因になる
556デフォルトの名無しさん:2013/11/20(水) 23:01:37.49
>>554
状態がstandardになってるものは規格だよ
557デフォルトの名無しさん:2013/11/20(水) 23:02:25.82
RFCを扱った人ならわかるはず
大文字「MUST」でなければ従わなくていい業界暗黙ルール
ちなみに
「SHOULD」=少しは頑張ってみて
「MAY」=ちょっとは気にかけて
だな
558デフォルトの名無しさん:2013/11/20(水) 23:11:40.97
rfc 791にはMUSTは一回も出現しないが、インターネットは従わないても構わない業界暗黙ルールで動いているのか。

こりゃ、びっくりだ 爆笑
559デフォルトの名無しさん:2013/11/20(水) 23:17:54.29
>>557
RFC791には「MUST」も「SHOULD」も書かれていない
という前提で言ってんだよな?
560デフォルトの名無しさん:2013/11/20(水) 23:22:23.99
>>557
RFCの歴史から見たら、およそ後ろ半分にしか存在しない新しいルールだな
561デフォルトの名無しさん:2013/11/20(水) 23:22:32.68
>>559
RFC791の頃にはまだお決まりのMUST/MUST NOT/SHOULD/MAYの話はなかったんだな
こりゃ失礼
562デフォルトの名無しさん:2013/11/20(水) 23:26:30.53
これが「決まりはない」のオチかよ^_^
563デフォルトの名無しさん:2013/11/20(水) 23:28:27.92
>>562
いいえ。
英文を正しく理解してね。
564デフォルトの名無しさん:2013/11/20(水) 23:30:20.54
少なくとも1989年のrfc1122あたりでは"MUST"が出始めてるな。
およそあの時期からの流行だったと思う。
565デフォルトの名無しさん:2013/11/20(水) 23:32:18.33
さて、もう寝るので明日朝までに回答よろしく。
答えにたどり着けなかったり、その他の逃げは敗北宣言とみなすので
よろしく。

自分で貼った英文に答えはあるのに、なんでわからないかなぁ?
だまされたと思って翻訳して貼ってみれば気づくかもよ?
じゃあ頑張ってね。
566デフォルトの名無しさん:2013/11/20(水) 23:37:40.01
どうやら「MUST」がオチだったようだ
知らないなら最初から黙ってりゃいいのに
567デフォルトの名無しさん:2013/11/20(水) 23:45:33.29
>>566
ということにして、さっぱり理解できないこの話からは
とっとと逃げたいという敗北宣言ですか?w
568デフォルトの名無しさん:2013/11/20(水) 23:49:53.32
逃げ^H^H寝たんじゃないのか 爆笑
569デフォルトの名無しさん:2013/11/20(水) 23:50:29.06
>>545にルーターなんて一言も出てこないじゃん。
これが答え。
570デフォルトの名無しさん:2013/11/20(水) 23:51:56.97
>>569
これはひどい
571デフォルトの名無しさん:2013/11/20(水) 23:52:20.78
バカが逃亡したところで巻き戻しておくか

>>397みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが

> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
572デフォルトの名無しさん:2013/11/20(水) 23:53:35.56
573デフォルトの名無しさん:2013/11/20(水) 23:55:27.76
ダメとも書いてないからok
574デフォルトの名無しさん:2013/11/20(水) 23:58:02.67
書いてないものは認められません
書いてないからokとか、どこの底辺PGだよ
575デフォルトの名無しさん:2013/11/21(木) 00:02:00.29
書いてないことは好きにしてokだろ
576デフォルトの名無しさん:2013/11/21(木) 00:04:24.45
そもそもunreachの一種だろ
okって初めから書いてある
577デフォルトの名無しさん:2013/11/21(木) 00:04:43.07
書いてある事しか認められないなら、仕様書にソースコード書かなきゃならんな。大爆笑
578デフォルトの名無しさん:2013/11/21(木) 00:06:09.13
>>577
馬鹿?
ソースが仕様書だろ
579デフォルトの名無しさん:2013/11/21(木) 00:06:21.40
>>571
> その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが

どこぞの大学のNTPサーバーを使うのが日本で流行ったとき、
そのサーバーはDoS食らったような状態になったらしいな。
各々のクライアントとしては1パケット/1分より少なかったのにな。

m.root-servers.netにping打つのが同じように流行ったら
それは好ましいことだと思うか?
580デフォルトの名無しさん:2013/11/21(木) 00:08:13.44
ttl = 1の意味がわからないなら聞いてくれていいんだぜ?
581デフォルトの名無しさん:2013/11/21(木) 00:09:58.25
ttlはルーターで1減るとは限らない(どやぁ
582デフォルトの名無しさん:2013/11/21(木) 00:11:43.61
ttl = 1の案が出てきたのって>>397より後じゃね?
583デフォルトの名無しさん:2013/11/21(木) 00:13:32.13
47秒差で前
584デフォルトの名無しさん:2013/11/21(木) 00:18:12.12
ほんとだ1個前か
まあ、47秒差じゃ>>397の時点ではttl=1なんて聞いてないだろうけどな
ルートサーバにping攻撃するようにしか見えんわ
そんなのを挙げ足とって馬鹿じゃね?
585デフォルトの名無しさん:2013/11/21(木) 00:19:16.49
>>580
ヒヤリハットの法則でいくと
ttl=1でm.root-servers.netにpingを飛ばすやり方が一般化すると
その数十分の一はttl=1にし忘れる
586デフォルトの名無しさん:2013/11/21(木) 00:19:28.65
本人がいまさら必死の自己弁護wワロスw
587デフォルトの名無しさん:2013/11/21(木) 00:21:36.18
>>585
そんなことはこの作者のツールしか思いつかないから
100% ttl=1に決まってるだろうが
588デフォルトの名無しさん:2013/11/21(木) 00:24:55.15
>>584
自分では正しく間違っていないすごいアイデアだと思っていたのに
通報とか言われて恥かかされて相当に悔しかったんだろうな
そしてキレて荒らしになったと
589デフォルトの名無しさん:2013/11/21(木) 00:27:44.40
ttl=1じゃなかったとして、いったいどこに通報すんだよw
これ自体が笑わせる煽りじゃんw
590デフォルトの名無しさん:2013/11/21(木) 00:28:22.03
ド底辺が息吹き返してきたか?
不文律の説明してくれよ

>>397みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが

> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
591デフォルトの名無しさん:2013/11/21(木) 00:31:27.57
>>589
ttl=1じゃなかったら普通にwideに通報して注意喚起するだろ
そんなアプリが普及でもしたら大参事だし
592デフォルトの名無しさん:2013/11/21(木) 00:33:15.42
>>587
こういうどこでも良いから打ち続けられるpingの宛先として m.root-servers.net を候補にしてるのだが
それを選ぶのは良い選択かという話だろうが

一般論として、そこに向かって撃つのが最も妥当性が高いとでも言うつもりか?
593デフォルトの名無しさん:2013/11/21(木) 00:36:09.93
>>592
個別の案件で勝てないから、一般論を持ち出してきたか
個別の案件として100% ttl=1が保証されているのだから、
一般論がどうかに関係なく、全く問題はない
594デフォルトの名無しさん:2013/11/21(木) 00:42:05.17
>>592
ttl=1の時点で「打ち続けられるpingの宛先」じゃないんだよ
そこを理解できてないな
レコードが引ければ宛先はなんでもいいんだよ
m.root-servers.netのレコードを引くことすら、NSの負荷がとか
言いだすつもりかい?
595デフォルトの名無しさん:2013/11/21(木) 00:42:37.99
で、ttl=1なのに固定にする理由は?
596デフォルトの名無しさん:2013/11/21(木) 00:46:37.90
>>595
NDAで
署名した誓約書うpしな
597デフォルトの名無しさん:2013/11/21(木) 00:47:41.14
>>593
モデルガンを持って交番に行って警官に向かって打つふりをするようなものだよな
モデルガンだから問題ないと言ってるようだが
なんでわさわざそこを狙って打つことを肯定したがるんだ?
598デフォルトの名無しさん:2013/11/21(木) 00:48:27.05
>>597
馬鹿はたとえ話をするな
全く意味がわからないぞ
599デフォルトの名無しさん:2013/11/21(木) 00:49:19.84
>>533
増えると書いただけだが。
機器構成もホスト数もアプリ数も現状のトラフィック量もわからずに、何を見積もるの?
エスパー様にならわかるんだよねぇ?w
600デフォルトの名無しさん:2013/11/21(木) 00:49:35.98
>>597
バカの例えは問題を発散させるだけだからやめろ
601デフォルトの名無しさん:2013/11/21(木) 00:51:16.72
警官はモデルガンを向けられていることをわかるが、
m.root-servers.netはttl=1のpingの宛先にされていることを
知る由もない
たとえ話にすらなっていないな
602デフォルトの名無しさん:2013/11/21(木) 00:52:39.38
>>599
pingを最大1パケット/1分と条件つけてるので楽勝に見積もれる

全然問題ない
603デフォルトの名無しさん:2013/11/21(木) 00:54:04.39
>>597
ttl=1なので、交番に1歩向かった自宅の玄関でおしまいです。
そこでいくらモデルガンを打っても、何の問題もないし、
警官にもばれません。

はい論破w
604デフォルトの名無しさん:2013/11/21(木) 00:54:52.12
それで、ttl=1なのに固定にする理由は?
答えられないの?
605デフォルトの名無しさん:2013/11/21(木) 00:55:48.15
>>603
なんでわざわざそこ狙うのかという話だろ
606デフォルトの名無しさん:2013/11/21(木) 00:57:06.44
>>604
しつこいな
聞きたかったら誓約書うpしな
607デフォルトの名無しさん:2013/11/21(木) 00:58:01.67
>>605
なんで狙っちゃいけないんですか?
交番に勤務する警官を絶対届かない自宅玄関から狙っちゃいけないという
不文律wでもあるんですか?
608デフォルトの名無しさん:2013/11/21(木) 01:02:54.64
ttl=1でルートサーバーにping飛ばすのを流行らせたいテロ?
609デフォルトの名無しさん:2013/11/21(木) 01:03:43.79
>>607
むしろなんでわざわざ大事なルートサーバーを狙う?
610デフォルトの名無しさん:2013/11/21(木) 01:05:07.63
>>609
狙いたいから狙う。
狙っても一切無害だから狙う。
何か問題でも?
611デフォルトの名無しさん:2013/11/21(木) 01:07:32.06
>>609
大事なサーバーだから、レコードも大事に扱われるでしょう。
なので大事なサーバーゆえに狙うのです。合理的な考えでしょ?
誰もが大事にするからターゲットにする。でも一切危害は加わらない。
わかりませんか?
612デフォルトの名無しさん:2013/11/21(木) 01:09:23.03
>>606
じゃあ会社名と所属うp
613デフォルトの名無しさん:2013/11/21(木) 01:10:18.20
>>611
たった一つの失敗でルートサーバーにパケットが飛ぶんだけど

そういうやり方を流行らせたい?
614デフォルトの名無しさん:2013/11/21(木) 01:12:22.60
>>611
お前が綱渡りで遊ぶのは勝手だけど、失敗して他人に汚れが飛ぶような遊び方は止めろ
615デフォルトの名無しさん:2013/11/21(木) 01:12:56.68
>>610
なんで自分のサーバーを狙わないの?
616デフォルトの名無しさん:2013/11/21(木) 01:14:09.57
>>613
じゃあ、あなたは宛先をすべてルートサーバーにしてしまうかもしれない
失敗をしそうなので、インターネットをいますぐやめなさい。
ということと同義ですが?

たった1つの失敗といっても、言い出したらきりがないですね。
どうしてTTLだけ例外扱いして、その失敗だけが発現すると思うのですか?
むしろ、プログラムの構造上もっとも起きにくい失敗でしょう。
617デフォルトの名無しさん:2013/11/21(木) 01:16:07.91
>>614
失敗しませんのでご心配なく。
あなたがブラウザでURLを間違えて、知らないサーバに負荷をかけてしまう
可能性のほうが圧倒的に高いですから。
618デフォルトの名無しさん:2013/11/21(木) 01:16:21.43
>>613
失敗しないので
619デフォルトの名無しさん:2013/11/21(木) 01:18:51.05
>>615
勝手だろ。
実際にサーバーに負荷かけるわけじゃないんだし。
620デフォルトの名無しさん:2013/11/21(木) 01:24:38.83
>>619
じゃあなんで質問したの?なんで固定にする必要があんの?
621デフォルトの名無しさん:2013/11/21(木) 01:28:53.17
>>619
身勝手過ぎ
622デフォルトの名無しさん:2013/11/21(木) 01:30:12.25
>>617
> 失敗しませんのでご心配なく。

この根拠のない自信は何て言う病気?
623デフォルトの名無しさん:2013/11/21(木) 01:33:37.80
          ____
       / \  /\  キリッ
.     / (ー)  (ー)\
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |失敗しませんのでご心配なく
     \     `ー'´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))
624デフォルトの名無しさん:2013/11/21(木) 01:52:12.33
>>619は別人なので、間違えないように

>>620
前者の問には回答済み
後者は誓約書うpしたら教えてあげる、公的認証で署名すること

385 殿
誓約書
 このたび情報開示を受けるにあたり、以下の事項を厳守することを、ここにお誓いいたします。

.開示された情報は如何なる理由においても第三者に開示しません。
. 有償無償に関わらず、開示された情報に基づくソフトウエアの開発は行ないません
. 前項、前々項に反する行為を行った場合は、私の責任において情報の回収をおこない、損害金として金1000万円を支払います
以上 
平成   年   月   日
住所
氏名
625デフォルトの名無しさん:2013/11/21(木) 01:57:04.60
ほんものの基地街の人ですか
626デフォルトの名無しさん:2013/11/21(木) 02:03:57.90
最初から企業秘密といってる事をどーしても知りたいと言うので
そんなに知りたいならNDAでと言ってるだけ
627デフォルトの名無しさん:2013/11/21(木) 02:22:34.92
tcpdumpで観察してみると
TTL1のパケットが出る前に
UDPのパケットが大量に出入りしています ><
628デフォルトの名無しさん:2013/11/21(木) 04:34:55.72
>>602
だから、それ見積もって何か意味あるのかよ。
629デフォルトの名無しさん:2013/11/21(木) 06:05:01.75
>>624 >>626
385って何の385ですか?
ちゃんと会社名と所属と実名も出しなよ
もしかしてそんなこともわからなかったのかな?
630デフォルトの名無しさん:2013/11/21(木) 07:29:30.07
>>628
> だから、それ見積もって何か意味あるのかよ

こういうド底辺な発言をしなくて済む
>>529
> 同一ネットワークでそのプログラム使っているホストが沢山いたら、
> そこのデフォルトゲートウェイの負荷が増えるし、そういうアプリが
> 沢山あったら、ホスト自身の負荷も増えるな。

>>629
誓約書は片務契約なので債務者の身元だけだけはっきりしてればいい
こんなことも知らないの?
631デフォルトの名無しさん:2013/11/21(木) 07:52:10.95
債務者の身元しかわかってないと
仮に債務者が守秘義務違反を犯した場合に誰が損害賠償請求できるのかわかんないね
632デフォルトの名無しさん:2013/11/21(木) 08:23:16.00
>>622
テレビの見すぎ病
633デフォルトの名無しさん:2013/11/21(木) 08:36:26.10
片務契約だろうが、甲乙は対象の組織や個人を特定できるように
なっていないと契約として全く意味をなさない。
こんなことも知らないキチガイさん。
634デフォルトの名無しさん:2013/11/21(木) 08:53:15.89
>>631
んじゃRSA公開鍵

sha1: e9b7e1b653c38cb368f3a36340441c3dd82544ce
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoR/Xi5/CQIh3aOd/2xr4
5AI4SpLnuZh8JalC1xDvinAsTYuQdCA7D0Q9cbSjHilK6eQKXmPgoRJgDuLY3sEY
CZS/BH+v5SWt7Nr7nvRfwdsNnA1I7as8OcbvFQmhiH5Bn6FCOXRRFMUYqFiuXiXs
xN9KhNIYmdQI2Ed6wZqoHR3fppvut4bLJT3VS0bUmPpNTgMk6b/X/xHv0gpjqpug
6V1FwJjoLzon4I7yuQDS31zXtpq5g3yzgQt6ml8CaDogBcvpE+d2py/rv08b6DlP
Y6NIlIMoUbeUU+/TXGt0/nE6eR4j3ZisdkdsXssLAQr66t1Amd4Wg/8Um0ebo46z
eQIDAQAB
-----END PUBLIC KEY-----
635デフォルトの名無しさん:2013/11/21(木) 09:02:28.92
>>631のいう事はそれなりに合理性があるので、改訂してやったぞ。

385 殿
誓約書
 このたび情報開示を受けるにあたり、以下の事項を厳守することを、ここにお誓いいたします。

.開示された情報は如何なる理由においても第三者に開示しません。
.有償無償に関わらず、開示された情報に基づくソフトウエアの開発は行ないません
.前項、前々項に反する行為を行った場合は、私の責任において情報の回収をおこない、損害金として金1000万円を支払います
.損害金はhttp://toro.2ch.net/test/read.cgi/tech/1351670708/634(sha1: e9b7e1b653c38cb368f3a36340441c3dd82544ce)に掲載されたRSA公開鍵とペアになるRSA秘密鍵をもつ者に支払います。
以上 
平成   年   月   日
住所
氏名
636デフォルトの名無しさん:2013/11/21(木) 09:43:34.85
>>635
あれあれ?
>誓約書は片務契約なので債務者の身元だけだけはっきりしてればいい
>こんなことも知らないの?
じゃなかったの?
人からちょっと言われたぐらいでもう覆しちゃったの?
こんなに自身たっぷりに言ってるのに
637デフォルトの名無しさん:2013/11/21(木) 09:53:20.62
>>636
変わってない、やっぱ頭悪いなお前 ド底辺のバカさがよくあらわれている

そんな頭で「自身」たっぷりに煽っちゃったりして 爆笑
638デフォルトの名無しさん:2013/11/21(木) 09:55:48.54
天然のキチガイが荒らすとダラダラと長いな
639デフォルトの名無しさん:2013/11/21(木) 10:02:35.88
今日はどんなド底辺レスで笑わせてくれるんだろう

「自身」タップリなド底辺レス期待してるぞ
640デフォルトの名無しさん:2013/11/21(木) 10:06:57.04
触ってる連中も同レベル
641デフォルトの名無しさん:2013/11/21(木) 10:10:48.05
公開鍵だされてもホームレスかもしれないし
そんな自分の身元も明かせない奴の文書に署名なんてできないなあ
とっとと会社名と所属と実名を書きなよ
642デフォルトの名無しさん:2013/11/21(木) 11:06:35.91
643デフォルトの名無しさん:2013/11/21(木) 16:10:54.30
2chは10年以上見てるが
つまらん板の存在を今日初めて知った
644デフォルトの名無しさん:2013/11/21(木) 17:24:43.46
サイコーにアホな発言を晒して終了しとくか
こういうアホどもはなんの為に生きているんだろう

>>397
> From: [397] デフォルトの名無しさん <sage>
> Date: 2013/11/19(火) 09:57:58.97
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき

>>537
> From: [537] デフォルトの名無しさん <>
> Date: 2013/11/20(水) 21:50:57.43
> そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
> HopLimitとは違うのだよ。
645デフォルトの名無しさん:2013/11/21(木) 17:33:29.74
>>644
お前が何の為に生きてるのか疑問です。
646デフォルトの名無しさん:2013/11/21(木) 17:38:50.54
>>644
それがどのようにアホなのかをお前の言葉で説明できないなら
ただアホアホ言うだけで終わるしか能のないお前もアホの同類
647デフォルトの名無しさん:2013/11/21(木) 17:42:24.04
>>630
意味もなく見積もるド底辺かw
いるよね、形だけの意味ない文書書くやつ。
648デフォルトの名無しさん:2013/11/21(木) 18:52:58.32
>>644は天才なのできちんとアホなところを解説してくれる
649デフォルトの名無しさん:2013/11/21(木) 20:46:07.34
>>646, >>648
ここまで読んで理解できないアホには永久に理解できない

>>647
プログラムを作るときは常にリソースの負荷を考えながら作るもの
ド底辺は救いようがないな
650デフォルトの名無しさん:2013/11/21(木) 21:06:28.36
>>649
要求仕様の環境を読めよ。
負荷を抑えるのにはコストがかかるから、適切な負荷はあっていいんだよ。
できるだけ負荷を抑えるとか、できるだけ速くとか、意味のない仕様書しか書いたことないのか?
651デフォルトの名無しさん:2013/11/21(木) 21:19:21.52
>>649
誰が何を読んでどう理解するかは全然関係ない話。
お前は説明能力がないんだなと思われてる状況で
お前自身がその行動でそれを証明してるわけだ。
652デフォルトの名無しさん:2013/11/21(木) 21:26:43.57
>>649
ド底辺の典型だな
三菱インフォメーションシステムズもそうやって開発してたんだろうな w

>>651
無脳症に説明する能力は持っていない お前以外はわかってるから問題ない
653デフォルトの名無しさん:2013/11/21(木) 23:08:37.07
この業界、説明能力がないと大損だよな
654デフォルトの名無しさん:2013/11/21(木) 23:44:55.93
>>653
お前以外はわかってるから問題ない
655デフォルトの名無しさん:2013/11/22(金) 00:19:53.84
俺もわからないんだが。
656デフォルトの名無しさん:2013/11/22(金) 00:34:34.90
>>654
全員分かってないのでは?
657デフォルトの名無しさん:2013/11/22(金) 02:01:13.86
皆がなんとなくわかっているのは
恐らく目的に対してPingで解決する必要はないだろうなって事ぐらい
658デフォルトの名無しさん:2013/11/22(金) 07:15:37.08
みんなでpingすればDOS
659デフォルトの名無しさん:2013/11/22(金) 09:17:30.74
そんなに煽らんでも誓約書出せば教えてあげるよ 爆笑
660デフォルトの名無しさん:2013/11/22(金) 09:29:15.16
661デフォルトの名無しさん:2013/11/22(金) 10:13:51.12
>>635
>385 殿
厨房だな
662デフォルトの名無しさん:2013/11/22(金) 10:40:04.48
殿とか様とか各位とか
書式の特徴で会社名が判るとか都市伝説があったな
663デフォルトの名無しさん:2013/11/22(金) 10:41:34.66
くやしいのうwくやしいのうw

>>397
> From: [397] デフォルトの名無しさん <sage>
> Date: 2013/11/19(火) 09:57:58.97
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき

>>537
> From: [537] デフォルトの名無しさん <>
> Date: 2013/11/20(水) 21:50:57.43
> そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
> HopLimitとは違うのだよ。
664デフォルトの名無しさん:2013/11/22(金) 10:56:45.47
質問終わったならとっとと消えろカス
665デフォルトの名無しさん:2013/11/22(金) 14:16:16.25
イヤだね
ここが俺が唯一輝ける場だ
666デフォルトの名無しさん:2013/11/22(金) 15:49:25.57
こんなド底辺どもに遭遇できるスレは他にないからな

>>397
> From: [397] デフォルトの名無しさん <sage>
> Date: 2013/11/19(火) 09:57:58.97
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき

>>537
> From: [537] デフォルトの名無しさん <>
> Date: 2013/11/20(水) 21:50:57.43
> そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
> HopLimitとは違うのだよ。
667デフォルトの名無しさん:2013/11/22(金) 17:25:55.87
もしかして通報されて怒られた経験でもあるの?w
668デフォルトの名無しさん:2013/11/22(金) 17:50:21.28
通報はされてないけど
社内のネット缶から電話掛かって来て
怒られたことはあるな
「それがどうかしましたか?」
って言ってやったら黙ったけど
669デフォルトの名無しさん:2013/11/22(金) 17:59:41.48
かわいそう・・
周りの人が
670デフォルトの名無しさん:2013/11/22(金) 18:07:41.70
※上司に報告されてマイナス査定されたことは黙っておきます
671デフォルトの名無しさん:2013/11/23(土) 23:59:43.88
関連スレ
■■ネットワーク系ソフトウェア開発 その1■■
http://engawa.2ch.net/test/read.cgi/network/1020608765/
672デフォルトの名無しさん:2013/11/24(日) 10:55:59.96
原理原則論は現実の前では役に立たない
673デフォルトの名無しさん:2013/11/24(日) 13:53:03.75
こんなド底辺どもが存在しているという現実

>>397
> From: [397] デフォルトの名無しさん <sage>
> Date: 2013/11/19(火) 09:57:58.97
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき

>>537
> From: [537] デフォルトの名無しさん <>
> Date: 2013/11/20(水) 21:50:57.43
> そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。
> HopLimitとは違うのだよ。
674デフォルトの名無しさん:2013/11/24(日) 14:59:28.91
675デフォルトの名無しさん:2013/11/25(月) 14:02:04.85
iPhoneとかでWiFiのアクセスポイントに繋ぐと自動で認証画面のWebページが開くやつってどういう仕組みでやってるのかな?
676675:2013/11/25(月) 14:08:22.81
677デフォルトの名無しさん:2013/11/25(月) 14:22:59.23
proxy設定しといて、そのproxyが全部やるんじゃなかろうか
678675:2013/11/25(月) 14:28:05.44
>>677
それってアクセスポイントに接続したあと、ウェブブラウザを開いて80番とかで通信しようとしたときにトラップしてログインページへ誘導するするやり方だよね…

iOSでアクセスポイントに繋いだだけでWebブラウザを開いてないのに自動で >>676 みたいな認証画面がでるんだけど、この仕組みがわからんぬ。
679デフォルトの名無しさん:2013/11/25(月) 14:31:39.95
Windows でも 勝手に IE が開くときと 反応が全く無いときがあるな
ルーターとの相性っぽいが
680デフォルトの名無しさん:2013/11/25(月) 14:42:47.19
681デフォルトの名無しさん:2013/11/25(月) 14:46:53.63
682675:2013/11/25(月) 14:56:57.02
>>680>>681
1. iOSでアクセスポイントに繋ぐ
2. SafariをアクティブにしていないのにWebページの認証画面が勝手に出る
という「勝手に出る」仕組みが知りたいわけなんだが…

>>680>>681だと、DHCPサーバからIPアドレスをリースされた後に、HTTP/HTTPSな通信がどのような方法で開始されたのか説明が無いので「勝手に出る」わからんぬ。自分でSafariを立ち上げて適当なWebサイトにアクセスする場合は分かる。
683デフォルトの名無しさん:2013/11/25(月) 15:03:19.20
勝手に出るかな?
プロファイル入れてんじゃねーの?
684デフォルトの名無しさん:2013/11/25(月) 15:16:18.37
馬鹿には無理
685675:2013/11/25(月) 15:29:11.31
プロファイルを入れると開くようになるってこと?
例えばソフトバンクがプロファイルを仕込んでおくとソフトバンクが用意したFON FREE INTERNETにアクセスした時に開くようにできたりするってこと?
技術名称が分かればあとは自分でなんとかできるんだが
686デフォルトの名無しさん:2013/11/25(月) 17:35:51.34
687デフォルトの名無しさん:2013/11/25(月) 17:38:53.73
Windowsはこれだな
http://www.viva-musen.net/archives/21062046.html
Macは知らん
688デフォルトの名無しさん:2013/11/25(月) 17:45:27.25
キャプティブポータル認証 ?
689675:2013/11/25(月) 17:50:17.28
キャプティブポータル認証って言うのか
http://makoro.hatenablog.jp/entry/2013/09/25/123840
だいぶ近づいてきた!
ありがとう
690デフォルトの名無しさん:2013/11/25(月) 17:52:18.15
691デフォルトの名無しさん:2013/11/25(月) 17:58:20.21
これが彼の逮捕のきっかけになるとは
その時は誰も知るよしもなかった
692675:2013/11/25(月) 18:00:51.73
いやいみわからんがなw
693675:2013/11/25(月) 18:01:22.94
ハニポとかしないからw
694デフォルトの名無しさん:2013/11/26(火) 04:20:00.06
iOSの話題でスレチだと思うが
ttp://kishi-r.com/archives/725
695デフォルトの名無しさん:2013/11/28(木) 20:28:14.04
誰かを襲う可能性があるからインターポールに通報すべき
こういうアフォは駆除しなきゃいけない
696デフォルトの名無しさん:2013/12/01(日) 07:50:29.15
本人にそのつもりは無くても
捕まるときは捕まるからなぁ
697デフォルトの名無しさん:2013/12/09(月) 11:16:00.76
194.85.61.0/24 が糞な件
698デフォルトの名無しさん:2013/12/14(土) 07:43:46.72
>>697
class C まるごと乗っ取られてるなω
699デフォルトの名無しさん:2013/12/14(土) 13:03:17.94
rawsocketについて教えて下さい。
Windows8.1 VC12でプロミスキャスモードを利用してデスクトップアプリ(chrome)の通信をキャプチャしようとしています。
送信パケットは取れるようになったのですが、受信パケットが取得できません。
該当しそうな単語でググってはみたのですが手詰まりでして…。
見つけたサンプルプログラムをビルドしてみても同様でした。
Wiresharkではう見れているので最終的にはWinPCap使えばなんとかなるとは思うのですが、何か思い当たることがあれば御教授頂けますでしょうか。
700デフォルトの名無しさん:2013/12/14(土) 23:19:23.42
>>699
Windowsファイアウォール無効にしてみた?
701デフォルトの名無しさん:2013/12/14(土) 23:23:32.51
>>699
窓板で聞けよ
702デフォルトの名無しさん:2013/12/15(日) 02:33:30.70
>>700
それでした。
通信許可する一覧に追加したら受信パケットも取れるようになりました。
些細なことでお手間とらせました。ありがとう。
703デフォルトの名無しさん:2014/01/15(水) 13:09:47.66
誘導されてこちらに来ました

質問内容は2つです。
1.ファイルディスクリプタをselectに設定する際の値
2.boost がコンパイルエラー


1.ファイルディスクリプタをselectに設定する際の値
select の第1引数であるnfds の値ですが、いくつかのソケットの値をorで計算した値
を放り込もうと思っています。ソケットの値+1にはなりませんが、
そんなに違わない数字になるので良いと思っていますが、
なにか大きな弊害等ありますでしょうか?

2.boost がコンパイルエラー
gcc 4.3 を使っています。
boost を利用したくて、ソースをzipでダウンロードし、b2でコンパイルすると
# error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
というエラーが出ます。
調べてもなかなかそれらしい対応策がみあたりません。
なにかアドバイスがあれば宜しくお願いします。
704デフォルトの名無しさん:2014/01/15(水) 15:12:11.40
>>703
> 1.ファイルディスクリプタをselectに設定する際の値
man selectしろアホ

> 2.boost がコンパイルエラー
スレ違いじゃボケ
705703:2014/01/15(水) 15:14:44.10
>>704


だから、man select いわくSOCKET + 1 だけど、少しだけ大きいことが大きな問題になるの?
って質問なんだけど?

2.に関して誘導してもらえると助かります。
706デフォルトの名無しさん:2014/01/15(水) 15:16:27.42
>>703
「ソケット select nfds」でググるとトップに「select(2)の第一引数にディスクリプタの最大値を渡すのは間違い?」という
ページがヒットするんだが、当然ここは読んだんだろうな?
707デフォルトの名無しさん:2014/01/15(水) 15:21:08.70
>>705
> だから、man select いわくSOCKET + 1 だけど、少しだけ大きいことが大きな問題になるの?
> って質問なんだけど?
しるかボケ
心配ならソース読め

> 2.に関して誘導してもらえると助かります。
この板のスレ一覧をboostで検索することも思いつかないのか
708デフォルトの名無しさん:2014/01/15(水) 15:24:54.82
>>706
そのページのリンク先のMicrosoftのページには
> nfds [in]
> Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
って書かれてるね。
709デフォルトの名無しさん:2014/01/15(水) 15:31:06.41
manでmax(all fds)+1を渡せって書かれてるのに、なんでそれに従いたくないの?
710デフォルトの名無しさん:2014/01/15(水) 15:52:33.56
>>707
知らないならノイズが増えるだけだから回答を差し控えようよ
711703:2014/01/15(水) 16:13:14.75
>>706
おおおおお
私はあなたを愛してる

ちょびっと感動。
712703:2014/01/15(水) 16:18:14.90
>>708
うむむ

この悩み多き子羊に悩みをふやすとは。
実は、Windowsベースで開発するか、Linuxベースで開発するか、JavaなのかC++なのか
悩み多き状態でありまするです。

bdb を別の目的で使っているのでなんとなく感動ですが、
変にブロッキングされないのであれば、どーーーんと大きな値をってやつですかね?
713703:2014/01/15(水) 16:21:29.31
>>709
非常に単純なコーディングの問題

大して適当な大きな値で問題なさそげなのに、なぜnfds + 1 なんだろうか?、と
#死んでもタイムアウトは使わんポリシーは維持しております四

この場合、fdsの値を計算で出すにしろ、もうっちっと適当な値でも問題ないのでは?と
そうするとコードが非常にシンプルになりまする
714デフォルトの名無しさん:2014/01/15(水) 16:43:20.13
そんな手抜きコードでシンプルとかお前終わってるよ
715703:2014/01/15(水) 16:47:38.37
>>714
終わってるかもねぇ
ただ、最大値+1で無くとも動くのになぜ、最大値+1なのかに疑問が生じたから、とだけ言っておこう
716703:2014/01/15(水) 16:49:20.70
>>710
ノイズにしなければよいかと思います。

>>707
ttp://mattn.kaoriya.net/software/lang/c/20090114140035.htm
を読んだ感想を一言だけ言わせればよいのでは?と思う次第です。
717デフォルトの名無しさん:2014/01/15(水) 17:01:03.05
>>713
そんなところを悩みどころにしてるようじゃ、まともなプログラムなんて到底書けないから
仕様通りに書いても大して難しいコードにならないのに
718デフォルトの名無しさん:2014/01/15(水) 18:16:58.47
>>715
> ただ、最大値+1で無くとも動くのになぜ、最大値+1なのかに疑問が生じたから、とだけ言っておこう
だから知りたきゃコード読めば正解がわかるだろボケ
719デフォルトの名無しさん:2014/01/15(水) 18:18:13.20
>>716
>>706も707も俺だし
720デフォルトの名無しさん:2014/01/15(水) 23:48:25.09
久振りにきたら沸いてるね
721デフォルトの名無しさん:2014/01/27(月) 14:34:08.34
いつ来ても涌いてる
722デフォルトの名無しさん:2014/01/27(月) 21:33:39.15
送信先のNICを指定したいんだけど
どうしたらいいかな
723デフォルトの名無しさん:2014/01/27(月) 22:42:26.60
Linux なら SO_BINDTODEVICE
他の環境は知らん
724デフォルトの名無しさん:2014/01/28(火) 00:57:44.05
>>723
ありがとう! これは素晴らしい
オレのインターフェースにSO_BINDTODEVICEしてもいいよ


ていうか、いつのまにこんなオプション出来てたんだろ・・・
ソケットってどんどんオプション増えてくな
725デフォルトの名無しさん:2014/01/31(金) 02:48:10.75
socatコマンドで、接続元IPアドレスを知りたいんだけど
環境変数かなんかで見れたりする?
726デフォルトの名無しさん:2014/01/31(金) 07:49:17.49
>>722
奴らは街角で拉致られてタコ部屋に押し込められて強制労働させられてるのか?
自ら希望して派遣会社に登録したんじゃないのか?
まずそこをハッキリして貰いたいんだが。
727デフォルトの名無しさん:2014/01/31(金) 11:23:34.57
NICってそんなに恐ろしいのか
728デフォルトの名無しさん:2014/01/31(金) 16:43:15.95
確かにでかいルーターに押し込められてる NIC はタコ部屋って感じがするな (w
729デフォルトの名無しさん:2014/03/02(日) 00:01:59.17
windoswにおけるネットワーク通信はすべて
winsockライブラリを通して行われているの?
730デフォルトの名無しさん:2014/03/02(日) 00:33:53.49
win dos (w
731デフォルトの名無しさん:2014/03/02(日) 16:06:50.91
widsdomはない
732デフォルトの名無しさん:2014/03/02(日) 16:15:30.12
netbios.dll は何もしないのか
733デフォルトの名無しさん:2014/03/13(木) 16:29:44.87 ID:4dqOfNxj
winsockの勉強を始めてconnect使ってみたんだが適当なアドレス(111.111.111.111とか0.0.0.0)とか入れてみても全くSOCKET_ERRORを吐いてくれない
これってこういうもんなんですかね?
734デフォルトの名無しさん:2014/03/13(木) 16:54:51.16 ID:dvaQTbQU
UDP
735デフォルトの名無しさん:2014/04/15(火) 11:58:23.72 ID:FRZaT020
openssl
736デフォルトの名無しさん:2014/04/15(火) 12:32:59.42 ID:WaetxQT9
先に進めてみればわかる
737デフォルトの名無しさん:2014/05/17(土) 23:03:21.87 ID:gMQ/DgzW
特定のマシンにARPパケット投げて、
ARPテーブルのMACを書き換えているのですが、
無線LANの場合、期待通りになりません。
原因わかりますでしょうか?

Windowsで最新WinPcapライブラリ使って
ARPパケットを投げています。
両マシンとも無線LANで同じネットワークです。
アクセスポイントの問題かな。
738デフォルトの名無しさん:2014/05/17(土) 23:13:54.36 ID:G8Lb2FJE
MAC偽装しているなら、無線区間のMAC偽装はWinPCAPではできない
739デフォルトの名無しさん:2014/05/19(月) 23:06:58.53 ID:8NVWe51U
>>738
なるほど、そういうことでしたか、納得。
740デフォルトの名無しさん:2014/05/21(水) 21:05:00.89 ID:e27UFOXq
WinPcapライブラリの使い方の良い情報源はないでしょうか?
できればC#から使いたい
741デフォルトの名無しさん:2014/05/21(水) 21:08:37.78 ID:v/u6M390
WinPcapNet
742デフォルトの名無しさん:2014/05/22(木) 08:51:43.06 ID:pX1Bpa+a
ありがとう
743デフォルトの名無しさん:2014/06/07(土) 14:27:22.26 ID:8MnQl1Rb
ここにいる人たちには初歩的なことかもしれませんが、教えてください
Linuxでソケットを使ったプログラムを作っているのですが、少し大きめのデータを何個かsend,recvした後に
サーバ、クライアントでcloseするとconnection reset by peerが時々出るようになりました。
closeするタイミングによってまだ残っている処理(send,recv)が取り残されているように思うのです。
サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか?
よろしくお願いします
744デフォルトの名無しさん:2014/06/07(土) 15:13:58.52 ID:pYRByoGi
>>743
通常はcloseしても送信しきる先に切られることは無いので
別のことが原因と思います
745デフォルトの名無しさん:2014/06/07(土) 15:38:02.72 ID:8MnQl1Rb
>>744
有難う、もう少し探ってみます。
746デフォルトの名無しさん:2014/06/07(土) 16:35:42.74 ID:ZfdboDuT
>>743
>サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか?

クライアントとサーバ上のアプリケーション間通信について、
以下のケースに応じて通信の終了に関する規約(プロトコル)を決める

(1) データ送信が必ず一方向のケース(例:パイプ)
 送信側は任意にcloseできるが、受信側ではソケットからの
 終了通知(データ長=0)を待ってからcloseしなければならない
(2) 要求/応答のペアからなるトランザクションが常に同一側で発生するケース(例:HTTP/FTP/SMTP)
 要求メッセージ送信側は任意にcloseできるが、応答メッセージ送信側では
 ソケットからの終了通知(データ長=0)を待ってからcloseしなければならない
(3) データ送信要求が任意の時点かつ双方の側で発生するケース
 制御メッセージとして通信終了要求(例:"QUIT")と通信終了応答(例:"OK")を定義し、
 正常に通信を終了させたい時は終了要求メッセージを送信し応答を待つ
 要求を受信した終了受け入れ側では応答メッセージを送信して即座にソケットをcloseする
 終了要求側では応答メッセージ受信を確認してからソケットをcloseする

(3)のケースは複雑な手順を踏まなければならないのだから、連動テストで問題が発生してから
解決策を悩むのではなく、上流の設計工程でアプリケーション間通信プロトコルの全体を
ステートマシンとして形式的に定義し、正当性を検証しておくことが望ましい
747デフォルトの名無しさん:2014/06/07(土) 16:56:39.59 ID:afR3dkD/
>>746にあるとおり、アプリケーションレイヤのプロトコルを決めてないところに問題があると思う
このメッセージを送信したらcloseする、このメッセージを受信したらcloseする、とか

mibをダンプするコマンド(nstatとか)でTcpExtTCPAbortOnCloseがインクリメントされてたら、
>>743の推測通り、アプリケーションがメッセージを吸い上げる前にcloseが発行されてると思う
748デフォルトの名無しさん:2014/06/07(土) 22:16:48.00 ID:oYteh1Pa
無線で電波が途切れた場合とかどうテストしたらいいん?
749デフォルトの名無しさん:2014/06/07(土) 22:32:20.13 ID:ZfdboDuT
>>748
・単体テストであれば、スタブ側で電波途切れのエラーを返す
・有線で組み通信中にケーブルを引き抜き擬似的に現象を起こす
・金属ケースや地下室などの電波を遮蔽できる環境を用意する
頭を使えば、様々なアイデアがでると思うよ
750デフォルトの名無しさん:2014/06/07(土) 22:39:04.87 ID:D6sqOe5Q
>>748
どのレベルのプログラムの話なんだ?
ドライバ?ネットワークスタック?アプリケーション?
751デフォルトの名無しさん:2014/06/07(土) 22:49:51.34 ID:yvNnNrOK
>>748
ノートPCを持って電波が途切れる所まで離れてみる
青歯で実際にやったことあるぞww
752デフォルトの名無しさん:2014/06/07(土) 23:30:00.41 ID:1rlrU+oI
相手の電源切ればいいじゃん
753743:2014/06/12(木) 20:36:17.42 ID:ahExhbNy
>>744, 746, 747
レス有り難う御座います。
暫く調査をしていたら原因らしきものを特定出来ましたので報告します。
結果的にはネットワークプログラミングには関係無い所でした。

スレッドの動作状況を確認するカウンタみたいな変数を作ってアクセスしていたのが原因で、
mutexを使っていないのがいけなかった様です。 orz...
メモリの同時アクセス→何らかの例外が発生→何故かGlibmm-ERROR std::bad_allocが発生→
selectやらrecvやらでソケットが無効となる→相方のプロセスでconnection reset by peerとなる
という感じでした。

何らかの例外ってのがあやふやなのと、元々あまり発生しないエラーだったので本当に解消できたのか
不安なところはあります。お付き合い頂き有難う御座いました。
754デフォルトの名無しさん:2014/06/13(金) 14:04:40.40 ID:El4cLTno
ところで相手がデータ受けとる前にcloseしたら
相手がデータ受けとる前にセッション切られてしまうという誤解、
これ広まったのはいつ頃からなんだろうか。
とても気になるな
755デフォルトの名無しさん:2014/06/13(金) 14:25:16.96 ID:3lbuf2Ok
ハーフクローズでデータ受けるとRST返してしまうから
相手側はデータ受け取る前にセッション切られるんだよ
FINに対してFIN/ACKを返したときはrecvでデータ受けきることができるけど
RST受けたときはその時点で終わりという実装が多い
誤解というか最悪ケースってやつで、セッションは切られるかもしれない
前提で設計しないと、ひどい目にあうっていう話だね
756デフォルトの名無しさん:2014/06/13(金) 14:31:08.01 ID:XjONkcPz
ちょっとそれだけだと詳細がわからないな
その広まってる誤解っての寡聞にして知らないんで、
具体的におしえてくれないかな?
とりあえずTCP?
757デフォルトの名無しさん:2014/06/13(金) 14:33:38.70 ID:XjONkcPz
>>755
ごめん、>>756>>754に対してです
書き込み時間がかぶってしまいました
758デフォルトの名無しさん:2014/06/13(金) 20:30:15.17 ID:w1vYKm0h
>>754
> ところで相手がデータ受けとる前にcloseしたら

この行のclose操作は送信側で起きるんだよね?
(受信側はrecvで待ち続けているのだから....)
もしそうだとしたら、

> 相手がデータ受けとる前にセッション切られてしまうという誤解、

のような話は聞いたことがない
というか、TCPコネクションが双方向のパイプ(バイト・ストリーム)として
モデル化されることを理解していれば、誤解など起きるはずもない
実際、>>746のケース(1)は、送信側が任意のタイミングでclose操作が
起きることを想定しているけど、これはUNIXのパイプと同じだから、
一部でもデータが喪失することを発想してしまうのは信じ難いな....
759デフォルトの名無しさん:2014/06/13(金) 20:54:45.67 ID:cTbIwDgy
>>758
世の中にはその辺あんま理解してない子が結構いるのよ
760デフォルトの名無しさん:2014/06/13(金) 20:58:09.95 ID:Wxssly4Y
読む気がしないが分かっていなさそうなのは分かる
761デフォルトの名無しさん:2014/06/14(土) 21:34:42.63 ID:BuWNtkHZ
WSAAsyncSelectを使用して非同期通信をしています

通信経路はクライアントAがサーバーへ送信してからサーバーがクライアントA以外のクライアントへ送信するようにしています

ここで質問なんですが
1, クライアントAがデータA「0123456789」を送信してサーバーがデータAを受信し終わる前にクライアントBがデータB「ABCDEFG」を送信して分割して受信された時の挙動は
 A, データAの「01234」「56789」を受信し終わってからデータB「ABC」「DEFG」を受信
 B, データAの途中でもデータBが届く場合がある「01234」「ABC」「56789」「DEFG」
どちらですか?
762デフォルトの名無しさん:2014/06/14(土) 21:37:49.47 ID:BuWNtkHZ
TCPですすみません
763デフォルトの名無しさん:2014/06/14(土) 22:01:22.78 ID:DYTXSKWp
TCPですすまないならUDPでやれば
764デフォルトの名無しさん:2014/06/14(土) 22:08:43.87 ID:z28CrNoH
順序は保証されてるでしょ
分割の切れ目がどこになるか保証されないだけで
765デフォルトの名無しさん:2014/06/14(土) 22:20:09.59 ID:BuWNtkHZ
>>764
つまり分割されたとしてもデータAを受信し終わってからデータBを受信開始なんですね
ありがとうございました
766デフォルトの名無しさん:2014/06/15(日) 00:05:02.11 ID:LTwXYkm1
あらやだ
767デフォルトの名無しさん:2014/06/15(日) 00:24:56.25 ID:oWCenAVd
>>764
Bになりえるだろバカ
768デフォルトの名無しさん:2014/06/15(日) 01:52:52.97 ID:MXV8DDuP
バーカ
769デフォルトの名無しさん:2014/06/15(日) 04:08:33.04 ID:M5otKvxk
>>761
TCPスタックから見ればパケットが届く順はBになりえるけど、
アプリケーションの作り方として、最初にacceptしたコネクションから
全データをreadするまで別のコネクションはacceptしないとか、
acceptはしても最初のコネクションの分割メッセージを全部受信し切るまで
別コネクションのデータはreadしないとかにすればAになるかな
770デフォルトの名無しさん:2014/06/15(日) 06:43:01.77 ID:Rg7+Zgkt
アプリケーション側での受信順のためにわざわざそんな変な造りにするのは本末転倒な気がする。
771デフォルトの名無しさん:2014/06/15(日) 08:25:20.91 ID:9Vq05/27
A:煙草吸ってもよろしいですか?
B:どうぞ。ところで一日に何本くらいお吸いに?
A:ふた箱くらいですね。
B:喫煙年数はどれくらいですか?
A:30年くらいですね。
B:なるほど。あそこにベンツが停まってますね。
A:停まってますね。
B:もしあなたが煙草を吸わなければ、
C:ちくわ大明神
B:あれくらい買えたんですよ。
A:あれは私のベンツですけど。
B:誰だ今の
772デフォルトの名無しさん:2014/06/15(日) 08:50:36.80 ID:U90s9FoP
最近は馬鹿が出没してるらしいですわよ、気をつけなきゃ
773デフォルトの名無しさん:2014/06/15(日) 08:57:05.82 ID:0kRzHgJN
そうわよ(便乗)
774デフォルトの名無しさん:2014/06/15(日) 18:18:26.97 ID:XcHbJsG3
>>761
正解は「C, 挙動は非決定的であり事前に予測できない」になる

つまり A かもしれないし B かもしれないし、その他の挙動が起きるかもしれない
たとえば「0A1B2C3....」もあれば、最悪のケースだと「ABCDEFG12345...」もありえる
あるアプリケーションがsend操作を発行して全データを送信し終えたとしても、
それはあくまでソケットAPIへの送信要求が完了しただけであって、
そのデータを相手側アプリケーションが「いつ」受信するかを事前には予測できない

一般にデータ受信側アプリケーションでは、バッファ上でメッセージを組み立てる
つまりメッセージの終端に到達するまでselect+recv操作を反復してバッファに保存し、
終端に到達したタイミングでバッファからメッセージを取り出して受信手続きを実行する
サーバでは、この一連の手順を各クライアントごと並行に処理することになる
775デフォルトの名無しさん:2014/06/15(日) 18:22:01.25 ID:QaOmTGzv
ここで後だし
776デフォルトの名無しさん:2014/06/15(日) 22:09:55.41 ID:9Vq05/27
A:かもしれないし
B:かもしれないし
C:ちくわ大明神かもしれないということですよ
777デフォルトの名無しさん:2014/06/15(日) 22:30:55.41 ID:e0YOs29w
>>776
正解はBだが、Cのちくわ大明神は現れない場合もあることを想定する必要がある。
TCPの場合、ちくわ大明神が現れなくてもリトライしてはいけない。
なぜならばTCPの中の人がちくわ大明神を呼び出してるから。
778デフォルトの名無しさん:2014/06/16(月) 01:27:25.37 ID:Hr3juoVp
中だし
779デフォルトの名無しさん:2014/06/16(月) 01:55:14.21 ID:Yg1Vykl/
UDPでパケットの到着順序は保証されないけど
実際に順序ひっくり返してみたいんだけど
どういうふうに試験環境用意すればいいかな。
780デフォルトの名無しさん:2014/06/16(月) 03:23:40.68 ID:OlFzGfst
>>779
再現困難だから、実際にひっくりかえして送信(しても耐えられるかどうか)をするのがいいのでは?
781デフォルトの名無しさん:2014/06/16(月) 08:56:38.07 ID:qCCwIaT2
dummynetみたいなやつでエミュレートする
782デフォルトの名無しさん:2014/06/16(月) 19:23:49.43 ID:VjJmHSFF
accept 後の
それぞれのソケット(A, B) からみれば
ソケットA 「0123456789」 ←これが細切れになるやもしれない
ソケットB 「ABCDEFG」 ←これが細切れになるやもしれない
こういうことでないの?
783デフォルトの名無しさん:2014/06/16(月) 19:34:24.31 ID:lmeB/Wgi
パケットの分割自体はサーバー側で織り込み済みだ
いつまで引っ張る
784デフォルトの名無しさん:2014/06/16(月) 20:15:57.07 ID:4xh696zJ
socketでサーバを作成し、Teraterm(クライアント)から接続したのですが、
Telnetと同じように1文字ずつ、入力のたびにパケット送信したいのが、
Enter押したときにしかパケットが送信されません。
Teratermで 1文字入力する毎にパケット送信するためにはどうしたらよいでしょうか。
785デフォルトの名無しさん:2014/06/16(月) 20:59:22.15 ID:qCCwIaT2
適切な板とスレッドを選択して質問する
マニュアルを読む
ソースを読む

好きなのをどーぞ
786デフォルトの名無しさん:2014/06/16(月) 23:01:22.79 ID:H3LgDS+r
>>782
ソケットAとBから同時にサーバーに送信した場合の話をしてるんだが
ソケットAを受信し終わる前にソケットBの断片が届く可能性はある
787デフォルトの名無しさん:2014/06/17(火) 09:19:18.20 ID:aobUuG6A
>>786
そんな話をしていたのかよ
そんな順序誰も保証してないよ
788デフォルトの名無しさん:2014/06/17(火) 09:38:20.34 ID:AXTqfFKW
とんでもねー後出し
789デフォルトの名無しさん:2014/06/17(火) 10:50:08.08 ID:LnB6vTqT
>>787
>>761に書いてあるだろ

後出しでも何でも無いわ
790デフォルトの名無しさん:2014/06/17(火) 11:36:35.90 ID:v0ZbhD0U
>>789
わりー、どっちでもねーわ
791デフォルトの名無しさん:2014/06/17(火) 18:49:57.60 ID:7NsOcMoU
>>786
ソケット違うんだからデータが混ざったりしないし
順番なんてどうでも良いんじゃないのかい?
792デフォルトの名無しさん:2014/06/17(火) 18:52:25.29 ID:kfNgSsa5
ど素人なのだろ、ほっとけ
793デフォルトの名無しさん:2014/06/17(火) 19:38:55.74 ID:LnB6vTqT
>>791
どうでもよくないから>>761は聞いてるんだろ?
794デフォルトの名無しさん:2014/06/17(火) 19:58:35.02 ID:7NsOcMoU
>>793
WSAAsyncSelect()の第一引数を無視してるから混ざると困るって事だろねw
795デフォルトの名無しさん:2014/06/17(火) 20:03:30.59 ID:Kpke8le7
>>793
ファイルを2つオープンして、それらからデータをリードしている
ここで、2つのファイルのデータが混ざってしまう事を
心配しているのが>>786,791なんだよなあ

まあ、彼らのようなプログラミングの初心者にとって
複数ファイル処理は難しい課題なのかもしれないけど、
もしも>>761がそのレベルの課題を質問したいのなら
「ネットワークプログラミング」というスレの主旨から外れるから、
別の初心者スレで遊んでほしい
796795:2014/06/17(火) 20:05:55.36 ID:Kpke8le7
アンカをミスっていたので、訂正

X: 心配しているのが>>786,791なんだよなあ
O: 心配しているのが>>786,793なんだよなあ
797デフォルトの名無しさん:2014/06/17(火) 20:14:48.16 ID:7NsOcMoU
>>795
WSAAsyncSelect()を使った場合、ソケット毎に別の格納用のデータ構造が必要だって
のはネットワークプログラミングの範疇じゃないのかい?

WSAAsyncSelect()じゃなくてソケット毎に別のスレッドにすればそんな問題は発生
しなくなるがスレッドだとまた別の罠がある。
スレッドの罠はネットワークプログラミングの趣旨から外れるなw
798デフォルトの名無しさん:2014/06/17(火) 20:25:05.41 ID:m9diWqqq
データは混ざらないけど、時間軸で追っていくと、到着に規則性がないのが大前提 (だから、うまくやれ

時間→
A  "01234"    "567"      "89"
B       "ABC"    "DEFG"

Aが先に構築し始めてるけど
Aのメッセージ(123456789)が 完成する前に
Bのメッセージ(ABCDEFG) が完成することだってある

だから A用バッファ B用バッファ (>>797 でいうソケット毎に別の格納用のデータ構造) を用意し、
ハンドラで、A向けかB向けかを判断いたうえで、しかるべきデータ構造に詰んであげる必要がある
799デフォルトの名無しさん:2014/06/17(火) 20:27:31.50 ID:LnB6vTqT
>>795
元はクライアントA→サーバー→他クライアントへって処理だから
FD_READで同じ処理させればいいだけなんだし
ソケット分岐する必要があればソケット別に処理させて
ソケット分岐する必要がなければそこらへん意識せず処理するだけで終わるだろ

ファイルとか例えが下手すぎる
800デフォルトの名無しさん:2014/06/17(火) 20:28:42.17 ID:Kpke8le7
>>797
ファイル処理では、ファイル毎にファイル記述子を格納する
変数が必要なのは、常識ではないのか?
そんな常識すら知らない初心者に手取り足取り教えるのが
このスレの主旨だとは、少なくとも自分は思わない
801デフォルトの名無しさん:2014/06/17(火) 20:37:08.33 ID:Kpke8le7
>>799
デバイスの抽象化という概念を知らない素人が口出ししても
恥をさらすだけ
802デフォルトの名無しさん:2014/06/17(火) 20:45:51.47 ID:LnB6vTqT
>>801
何が気に障ったのかわからんが論点ずらさんでも
玄人は初心者とか素人って言葉使わないんだけどな
自惚れてる人が良く使う

>>761に対しては
Aが受信終わる前にBのデータが割り込む可能性があるから
ソケット毎にデータを処理するべきで終わってた話だろ
803デフォルトの名無しさん:2014/06/17(火) 20:54:06.90 ID:Kpke8le7
>>802
その終わっていた話に対して、わざわざボケをかましたのが>>793だろ

というか、ID:LnB6vTqT の理解レベルが、他と比べて低すぎる
無知は決して恥ではないけれど、無知であると自覚できないのは無能だ
804デフォルトの名無しさん:2014/06/17(火) 20:57:59.06 ID:7NsOcMoU
>>800
ファイルストリームではSelect()のように同じ所に返って来たりしないからな。
世の中には、ファイルストリームがストリームソケットになっただけで同じものなのに
わからなくなるヤツが居るのさ。

ま、言いたいことは分かるがそんなに目くじら立てるな。
805デフォルトの名無しさん:2014/06/17(火) 21:02:48.63 ID:7NsOcMoU
Winsockを使うのなら >>1 の2つ目のリンク先くらい見ておかないとね。
古いんで今では正しくない部分もあるがかなり参考になると思う。
806デフォルトの名無しさん:2014/06/17(火) 21:15:24.83 ID:Kpke8le7
>>784
ソケットオプション TCP_NODELAY を試せ
TCP_NODELAY でググると情報が見つかる

たとえば WinSock 向けなら、こんなのが:
・Winsock と TCP 経由で小さなデータ セグメントを送信する
  http://support.microsoft.com/kb/214397/ja
807デフォルトの名無しさん:2014/06/17(火) 22:00:07.12 ID:LnB6vTqT
>>803
話の流れ見てから言え
発端の前提をぶっ壊して話されてもな
エスパーでもないのに俺のレスのどこで理解レベルがわかるんだよ
>>761が危惧してた事を言ったまでだぞ

とりあえず誰かを見下したいなら他行け
808デフォルトの名無しさん:2014/06/17(火) 22:17:12.70 ID:Kpke8le7
>>807
見下すも何も、2つのファイルや2つのソケットを扱う処理で、
それらのデータが混ざってしまうことを危惧しているのは
ID:LnB6vTqT、ただ一人だけ

他の連中はクライアントを識別するはソケット記述子で判断できるという
常識を前提にして議論しているのに、ID:LnB6vTqTは知らなかったんだろ?
だから>>793みたいにトンチンカンなボケをかます

誰でも成長の過程で間違いをおかすことはあるんだから、
それを素直に認めたほうが前向きな生き方だと思うよ
809デフォルトの名無しさん:2014/06/17(火) 22:32:15.32 ID:LnB6vTqT
>>808
サーバー側が受信するデータの順番で言うと
データAとBが「01234」「ABC」「56789」「DEFG」と交互にくる可能性があるか聞いてるんだろ
つまり混ざるかどうか

>>808が言う所の混ざるとはrecv1回のデータの中にデータAとデータBが同時に存在するかどうか しないわな
>>761が危惧してるのは同じデータ領域を使用して末尾に受信したデータを連結した場合混ざるかどうか ソケットで分けたら解決
ここの認識がずれてるぞ

>>761がそういう危惧してるから>>761は聞いてるんだろって話

話の流れと質問者の意図を汲み取れよ
810デフォルトの名無しさん:2014/06/17(火) 22:36:12.06 ID:KLoAGEx3
汲み取りやてんの、下水が普及してないのか
811デフォルトの名無しさん:2014/06/17(火) 22:43:50.79 ID:7NsOcMoU
>>809
お前は何もわかっとらんのぅ。
812デフォルトの名無しさん:2014/06/17(火) 22:50:23.25 ID:m9diWqqq
A:FD_READ (recv:Aすれば 01234
B:FD_READ (recv:Bすれば ABC
A:FD_READ (recv:Aすれば 56789
B:FD_READ (recv:Bすれば DEFG

recv:A で得られたものと recv:B で得られたものを
1つのバッファに連結するという発想に陥っているのだろうか?

それとも、、recvの際にソケット識別子を(渡ってきたものを使わずに)自前解釈で決め撃ちしてるのか? 
813デフォルトの名無しさん:2014/06/17(火) 22:56:27.88 ID:LnB6vTqT
>>811
どこがや

>>812
ソケット毎に分けるという発想が>>761の時点で無いから
ソケットAもBも同じFD_READ・recvでやる前提と思うぞ
だからソケットAの受信が終わってからソケットBの受信開始なら現状維持でいいけど
recv1回目はソケットAのデータ、recv2回目はソケットBのデータってなる可能性があるなら変更しないといけないから聞いたんだろ
814デフォルトの名無しさん:2014/06/17(火) 23:00:25.44 ID:7NsOcMoU
>>813
複数コネクション張っておいてソケット識別子を使わないという発想はなんなんだ?

だったら、1コネクションしか受付け無いようにしとけば一挙に解決!
815デフォルトの名無しさん:2014/06/17(火) 23:10:21.03 ID:LnB6vTqT
>>814
受け取ったソケット識別子を使ってたとしても
受信順がソケットAが終わってからソケットBなら開始終了だけ知ってデータ格納先は1つでもいいけど
受信順がソケットAが終わる前にソケットBも来るならデータ格納先をソケット毎に用意しないといけないから
それで聞いてたんだろ
816デフォルトの名無しさん:2014/06/17(火) 23:10:21.69 ID:Kpke8le7
>>813
>ソケット毎に分けるという発想が>>761の時点で無いから

なぜ>>761にはソケット毎に分けるという発想が無いと断定できるのか?
もしかすると ID: LnB6vTqT はエスパーなのかもしれない(>>807)

あるいは「>>761 == ID: LnB6vTqT」だったりしてw
817デフォルトの名無しさん:2014/06/17(火) 23:11:09.44 ID:m9diWqqq
なんとなくゲスパー

FD_READ 受けた後の記述は recv(渡ってきたsockを受けた変数, バッファ)
だから表面上は同じものに見えてる

渡ってきたsockを受けた変数の 値が 適宜切り替わっているということに思い至っていないので、
値(識別子)による分離にたどり着かないのか
818デフォルトの名無しさん:2014/06/17(火) 23:12:20.50 ID:LnB6vTqT
>>816
また論点ずらしか?

ソケット毎に分けるという発想があったのなら
そもそもあんな質問出てこないだろ
819デフォルトの名無しさん:2014/06/17(火) 23:26:29.65 ID:XW/lVFuD
素人と汲み取り
820デフォルトの名無しさん:2014/06/17(火) 23:33:34.68 ID:7NsOcMoU
>>815
ソケット毎の格納領域を用意するのがそんなに手間なのかw
821デフォルトの名無しさん:2014/06/18(水) 08:12:17.54 ID:mKlf65Kz
ある程度力がつくと周りを見下し始める
ある程度極まってくると印象を気にし出す
天狗のまま戻ってこれない奴も多いけど
822デフォルトの名無しさん:2014/06/18(水) 11:30:08.66 ID:7tSp0AS9
0123456789が、01234, 56789に分割される程、フレームサイズの小さいL2プロトコルって何?
823デフォルトの名無しさん:2014/06/18(水) 12:08:34.89 ID:mKlf65Kz
例えに突っ込むアホ?
824デフォルトの名無しさん:2014/06/18(水) 13:34:53.47 ID:7tSp0AS9
最長データサイズの見積もり無しに、分割の可能性を心配する無能さをからかいたかっただけだよ。
825デフォルトの名無しさん:2014/06/18(水) 13:41:31.39 ID:wX3j5DNp
>>824
空気抵抗をゼロとする、って問題文を読んで
「そんなことあるわけねーよプゲラ」
って言っちゃうタイプだよね
826デフォルトの名無しさん:2014/06/18(水) 13:56:58.19 ID:7tSp0AS9
>>825
バカはたとえ話するな。空気抵抗必死で計算しようとしてるのが元質問者。
827デフォルトの名無しさん:2014/06/18(水) 14:01:36.18 ID:mKlf65Kz
>>826の例えの方がわからんわ

そもそもデータ受信時に割り込みがあるかどうかなんだから
最長データサイズの見積もりの必要なんて無いだろ
828デフォルトの名無しさん:2014/06/18(水) 14:12:31.35 ID:7tSp0AS9
L2のフレームサイズより小さければ分割は発生しないの
829デフォルトの名無しさん:2014/06/18(水) 14:33:45.09 ID:wp/txwFE
ソケット識別子を知らなかっただけなのに
なぜここまで続くのか
830デフォルトの名無しさん:2014/06/18(水) 14:44:51.76 ID:Djkr0MFk
>>828
MSSもWindow SizeもReveive Bufferも全否定かよ
831デフォルトの名無しさん:2014/06/18(水) 14:49:21.45 ID:mKlf65Kz
>>829
そうじゃなくね
Aなら受信データ格納先を1つで出来るが
Bなら受信データ格納先を複数用意する必要があるから聞いてたんだろ
832デフォルトの名無しさん:2014/06/18(水) 14:57:04.79 ID:DTSE9n1l
>>830
覚えたばかりの言葉を使いたいのはわかるけど、
意味を理解してから使いましょうね、ぼくちゃん
833デフォルトの名無しさん:2014/06/18(水) 15:43:47.55 ID:qLWFP7Um
IDが導入されて本当に良かった
834デフォルトの名無しさん:2014/06/18(水) 19:59:12.10 ID:CilgVW0U
>>829
Select系のAPIを使って居るのにソケット識別子を知らないのは痛過ぎるから
835デフォルトの名無しさん:2014/06/18(水) 20:49:29.47 ID:K2PaBBH0
>>824
TCP/IPの背景にあるインターネットワーキングとは、
不均質なサブネットワークが相互接続される世界である
ここで不均質(heterogeneous)とは、L1プロトコル、
転送速度、フレーム長等が混在している様相を指す
従って一般的な原則として、TCP/IPアプリケーションの
設計において特定のL2/L1プロトコルを前提にすべきではない

いいかえると、最長データサイズを事前に見積もりできるとする
発想のほうが初歩的な誤りであって、(>>761のように)任意のバイト境界で
データの分割や組み立てが起こりうることを想定して設計する姿勢が正しい
つまり、この件に関して言えば、
無能は>>761(ID: LnB6vTqT)ではなく、>>822(ID:ID: 7tSp0AS9)のほうだ

>>755>>822は、素人がネットワークを勉強して知識を得たけれど、
それをプログラミングへ生半可に適用させて火傷を負う典型的なケース
水平軸における対向するレイヤ間のプロトコルと
垂直軸における上位レイヤへ提供するサービス(インターフェイス)という
交差する2つの概念をごっちゃにして理解しているように思われる
836デフォルトの名無しさん:2014/06/18(水) 21:05:08.89 ID:YZhktGU/
IPoAC か
837デフォルトの名無しさん:2014/06/18(水) 22:13:46.39 ID:msRy+nk0
>>835はタコでおk?
838デフォルトの名無しさん:2014/06/18(水) 22:46:16.44 ID:CilgVW0U
>>837
ネットワークスレだけにオクトパスか
839デフォルトの名無しさん:2014/06/18(水) 23:11:37.86 ID:mKlf65Kz
>>834
>>761の疑問はソケット識別子を知ってるかどうかは関係無いだろ
840デフォルトの名無しさん:2014/06/19(木) 01:24:12.03 ID:AKnufCCZ
>>837
お前>>822か。 いい加減しつこいな。
841デフォルトの名無しさん:2014/06/19(木) 07:35:31.24 ID:ryr/zveK
タコがエスパー失敗
842デフォルトの名無しさん:2014/06/19(木) 09:04:54.78 ID:T3v2xG5Y
>>837
あらゆる可能性を想定出来ない奴がプログラミングとか趣味でやるだけにしとけ
843デフォルトの名無しさん:2014/06/19(木) 09:22:39.74 ID:WpG/iKEP
あらゆる可能性を想定してプログラミングを書くやつはタコ
仕様も知らん奴は趣味でプログラムするだけにしとけ
844デフォルトの名無しさん:2014/06/19(木) 09:40:15.71 ID:pZASkYhq
>>835
struct pkt {
int32_t size;
char data[*];
};
こんなパケットの先頭のsizeを読むときも
if (read(s, &size, sizeof(size)) != sizeof(size))
error();
としないのか、大変だな。頑張ってくれ。
845デフォルトの名無しさん:2014/06/19(木) 10:08:45.11 ID:T3v2xG5Y
>>843


>>844
発現しにくいバグ生むだろそれ
846デフォルトの名無しさん:2014/06/19(木) 10:47:52.19 ID:pZASkYhq
>>845
> 発現しにくいバグ生むだろそれ
意味不明
847デフォルトの名無しさん:2014/06/19(木) 10:51:52.22 ID:T3v2xG5Y
わからないならそのままでもいいんじゃね
848デフォルトの名無しさん:2014/06/19(木) 10:54:39.08 ID:D9TTjhOo
>>846
理解できるようになるまで勉強しろ
849デフォルトの名無しさん:2014/06/19(木) 13:37:52.71 ID:iC2KP732
>>845
仕様です。
って一言が、これほど上手く使えるとは。
850デフォルトの名無しさん:2014/06/19(木) 13:54:43.05 ID:T3v2xG5Y
>>849
おいw
851デフォルトの名無しさん:2014/06/19(木) 18:46:15.77 ID:BRW9+QBS
>>842
>あらゆる可能性を想定出来ない

「想定外です」霧
852デフォルトの名無しさん:2014/06/19(木) 18:48:43.70 ID:mP63aYGC
>>847
4バイト来ることを想定しちゃいかんって事かな?
あと、バイトオーダーも無視してるし
853835:2014/06/19(木) 20:24:00.87 ID:oi99l3rA
>>844
学校の演習課題で書くプログラムや個人の趣味プロジェクトであれば、
そのコードでもかまわないと思う
あるいは社会人であっても、研究職で研究対象としてのプログラミングなら許される
ただし、24時間365日の連続稼働という設計品質を要求される開発の最前線であれば、
コード設計の実装バグとしてレビューで指摘される

想像してみよう、銀行間で数十万件の取引レコードを転送している時、
偶然にもsizeの途中でデータが途切れてエラーとなったので
転送ジョブが異常終了してしまった
さて、この障害連絡に対して>>844はどう返答する?
「sizeの途中で途切れるなんて予測の想定外でした、私は間違っていません」
などと国会答弁の政治家のような言い訳をするのだろうね、たぶん

では「じゃあ、どうやって実装するのよ?」という想定質問について、
解決策は状況に応じていくつか考えられるけど、
最も汎用的なステートマシンを使う方法を過去スレPort24の類似質問に対して
疑似コード付きでレスしているので、まずはそちらを一読してもらいたい

 http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968

この過去スレの#318が自分のカキコになる
854デフォルトの名無しさん:2014/06/19(木) 20:25:55.76 ID:qy6t50nu
タコが釣れたぞ
855デフォルトの名無しさん:2014/06/19(木) 20:44:46.89 ID:mP63aYGC
>>853
今時は、全銀手順の手組なんてしないしw
ライブラリー使いましょ。

>>854
ネットワークスレなんだからオクテット足が釣れたと言いましょ
856デフォルトの名無しさん:2014/06/19(木) 20:47:19.72 ID:qy6t50nu
>>853
銀行で徹夜したことについて謝罪と賠償を請求する
857デフォルトの名無しさん:2014/06/19(木) 21:30:03.44 ID:lQ+uiTbF
良く読め、銀行間取引って書いてあるだろう?
日本は銀行間取引はRTGSで日銀経由でしている事を
知らない部外者だよ
858デフォルトの名無しさん:2014/06/19(木) 21:50:09.29 ID:Oxl/97Kx
タコはみずから足を出す 片山まさゆき
859デフォルトの名無しさん:2014/06/20(金) 00:17:58.19 ID:ZdNYCSgz
今読んでもノー爆は面白いよな
860デフォルトの名無しさん:2014/06/20(金) 06:36:54.81 ID:JSi28Lkj
>>853
ますます意味不明

ネットワークプログラミング相談室 Port24
http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968の#318
> 318 : デフォルトの名無しさん[sage] 投稿日:2009/08/12(水) 17:18:44
> >>315
> あー、そうか
> ローカルポートの情報も持ってないとだめですね

318で検索しても他にはないしなあ
861デフォルトの名無しさん:2014/06/20(金) 07:14:16.63 ID:kSpxa/vA
擬似コードって言ってるんだから
http://pc12.2ch.net/test/read.cgi/tech/1246895188/950-952
だろう

正直こんなくどいことせず1バイトずつ読めばいいと思うが、
レスもなんかくどいし、まあそういう人なんだろう
862デフォルトの名無しさん:2014/06/20(金) 07:33:26.53 ID:JSi28Lkj
>>853
> さて、この障害連絡に対して>>844はどう返答する?
error();
の中で処理する。

>>861
#318ではなく#938の可能性微レ存だが、銀行間の数十万件の取引レコードを
処理するプログラムを書く御仁がこんな単純な間違いをしたと、決めつける
のは良くない。本人の釈明を待つことにする。
863835:2014/06/20(金) 09:20:27.39 ID:fiYVjyLm
>>860
指摘ありがとう、レス#の間違いに気が付けなかった....

X: この過去スレの#318が自分のカキコになる
O: この過去スレの#938が自分のカキコになる

具体的な疑似コードは、過去レス(>>853)の #947 と #950-952
864デフォルトの名無しさん:2014/06/20(金) 10:59:08.88 ID:JSi28Lkj
> tlv = reader.get()
プログラムがここで寝ている時に通信障害の連絡やってきた。
さて、>>853はどう対処する?
銀行間の数十万件の取引レコードの転送の場合は当然
 switch (tlv.type) {
default:
error();
brreak;
 }
なんて事はしないんだよな。 w
865デフォルトの名無しさん:2014/06/20(金) 11:05:28.51 ID:JSi28Lkj
非同期(950-951)の場合

> 質問の意図に沿って「非同期I/Oを前提(だよね?)」とした場合、最も外側のTLV構造の処理は、
> ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。
こっちの場合も
 while (buf.size() > 0)
buf.size() == 0で抜けてしまうんだが、
 while (buf.size() > 0) {
}
if (state != STATE_COMPLETE)
error();
なんて事はしないんだよな。銀行間の数十万件の取引レコードの転送の場合は w
866835:2014/06/20(金) 11:57:20.19 ID:fiYVjyLm
>>864
「寝ている」とはプロセスがブロック(or スレッド)された状態を意味するのかな?
もしそうなら、過去スレ#950の冒頭で述べているように:
・マルチスレッド構成でTCPコネクション単位に
 スレッド処理する設計ならば、ブロックには何の問題も無い
 新たに受信データ断片が到着すればスレッドのブロックが解除され、
 次のtype別処理を再開できるのだから
・シングルスレッド構成でイベント駆動処理を前提に設計しているのならば、
 過去スレ#947の疑似コードは不適切だから
 代わりに#950の疑似コードを使えばいい

>>865
バッファが空である(buf.size() == 0)ならば
現時点で到着していた受信データ断片の処理は終わったのだから、
ステートマシンの状態を保持したまま
すみやかにコールバック関数をリターンし、
次の受信イベント発生を待ちうけるべき
こんなのはイベント駆動プログラミングの基本だけど、
>>865はどんなエラー処理を期待しているのかな?
867デフォルトの名無しさん:2014/06/20(金) 12:21:42.37 ID:JSi28Lkj
通信障害が発生してもreadは0を返さないのかな? 銀行間の数十万件の取引レコードの転送の場合は w
868デフォルトの名無しさん:2014/06/20(金) 12:58:00.74 ID:ZdNYCSgz
通信障害が起きたのならヘッダ部だろうとボディ部だろうと
途中でエラーになるんだから
安全を取って、その電文はエラーログに落として破棄、
ランプ光らせつつ再送に期待じゃない?
869デフォルトの名無しさん:2014/06/20(金) 13:01:45.74 ID:FGk8LmcM
そのためにタイムアウトがある
870デフォルトの名無しさん:2014/06/20(金) 13:06:50.29 ID:5fUr2YwO
何を言い争ってるのか知らんけど、
selectとnon blocking I/Oを使うんだぞ
それから実装はどうであれSOCK_STREAMのsocketからreadしたとき
何バイト読めるかは保証されていないぞ
871835:2014/06/20(金) 13:42:16.97 ID:fiYVjyLm
>>867
言われた事しかできません、という「ゆとり世代」かな?
しかたないから、面倒だけど疑似コードから実装コードへ落とし込む方法を
手取り足取り教えてあげよう
(実際に、要領の悪い新人さんを指導しているような気分になりつつあるw)

・イベント駆動を前提にした疑似コード#950であれば、
 OSやフレームワークからコールバックされた直後に
 readやreceiveシステムコールを発行してソケットから受信バッファに読み込み、
 それから#950の状態遷移関数 recv_acceptor をコールする
 (状態遷移関数内ではメモリ上のバッファだけを処理するから通信障害は無視できる)
 また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
 その部分で適切に通信障害発生時のエラー対応処理を実装する

・スレッドのブロックを前提にした同期プログラミングの疑似コード#947では、
 TLVリーダのget操作の中のシステムコール発行時に通信障害発生を判定する
 ただし、get操作がコードの複数箇所に拡散してしまうから、
 例外を投げるとかC言語ならlongjmpで大域脱出するとかして一ヶ所にまとめ、
 その部分で適切に通信障害発生時のエラー対応処理を実装する
 (もちろんget操作がエラーリターンするよう変更してもいいけど、可読性は落ちる)
872デフォルトの名無しさん:2014/06/20(金) 13:46:29.95 ID:UaHzai/N
とタコが申しております
873デフォルトの名無しさん:2014/06/20(金) 13:48:20.34 ID:+KfxKSN3
銀行系は言われてないことをやるとクビになるよ
874835:2014/06/20(金) 13:51:26.94 ID:fiYVjyLm
>>870
そのとおりで、TCP通信がバイト・ストリームであることを理解していれば、
保証されないことは当たり前なんだけど、それを保証するコード設計なんて
面倒くさくてやってられない、というのが>>844君の主張

>>844のコードだと、保証処理を放棄して、通信エラーとして扱うつもりでいる
875デフォルトの名無しさん:2014/06/20(金) 14:02:40.97 ID:JSi28Lkj
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
銀行間の数十万件の取引レコードの転送の場合は、通信障害でTCPの切断が起こっ
た事と通信終了でreadが0を返した事を判別できるのか?

それはビックリだよ。w
876835:2014/06/20(金) 14:56:31.68 ID:fiYVjyLm
>>875
まだ続けたいの?
しかたないね、新人教育を続けよう

・ここで扱っている受信メッセージ組立て処理の場合、
 メッセージ組み立て中の状態でreadが0を返せば、
 それは通信障害によるコネクション切断と判断する
 それ以外の状態、すなわち連続するメッセージ間で
 readが0を返した場合には判別できないから、
 単純に上位へコネクション切断を通知する

・上位のトランザクション処理ではトランザクション処理中に
 コネクション切断が通知されたなら通信障害と判断する
 ここで、トランザクションとは、たとえばHTTPサーバなら
 リクエスト受信開始からレスポンス送信完了までの期間を、
 SMTPであればHELLOコマンド受信開始からQUITコマンドに対する
 応答送信完了までの期間を指す
 それ以外の状態、すなわち連続するトランザクション間で
 コネクション切断が通知されたなら正常な通信終了と判断する

ビックリって、何を驚いているのかな?
もしかすると、こういった判定も面倒だからという理由で設計していなかったのね
まあ確かに、一般にネットワークプログラミングはエラー処理のかたまりだから、
慣れない素人さんや学生さんが最初にとまどってしまうのは無理もないのかな
877デフォルトの名無しさん:2014/06/20(金) 15:01:21.09 ID:JSi28Lkj
>  メッセージ組み立て中の状態でreadが0を返せば、
>  それは通信障害によるコネクション切断と判断する
後出し仕様 wwww

> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
下位レイヤーが上位レイヤーの状態を知ってるんですかあ? 銀行間の数十万件の取引レコードの転送の場合は。wwww
878835:2014/06/20(金) 16:00:42.03 ID:fiYVjyLm
>>877
> 後出し仕様 wwww

もともと過去レスの疑似コードでは、
readシステムコールを発行する詳細コードを抽象化し、
TLVリーダやバッファといった用語を書いている
そして、その実装は各自で考えてもらえばいいと思っていたけど、
ID:JSi28Lkj君が「僕には実装方法が分かりません」と言い出したから
丁寧に教えてあげているだけだよ


> 下位レイヤーが上位レイヤーの状態を知ってるんですかあ?

知らないから、下位の受信メッセージ組立て処理では
  「単純に上位へコネクション切断を通知」して
  上位のトランザクション処理に判別を委ねると、
>>876で述べている
もう少し冷静になって文章を読んだほうがいいと思うよ
こちらでは技術関連は指導できても、日本語の読解能力までは面倒みれないから
879デフォルトの名無しさん:2014/06/20(金) 16:10:48.55 ID:ix5aqk/e
大型はハードウェアがなんでもやってくれる、らしい(適当)
880デフォルトの名無しさん:2014/06/20(金) 17:15:41.46 ID:fmtXRHPg
>通信障害でTCPの切断が起こった事と通信終了でreadが0を返した事を判別できるのか

通信障害は-1が返ってくるし
881デフォルトの名無しさん:2014/06/20(金) 17:37:38.06 ID:qd8xX9Tw
>>874
> TCP通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
882デフォルトの名無しさん:2014/06/20(金) 17:40:23.44 ID:JSi28Lkj
>>878
> 知らないから、下位の受信メッセージ組立て処理では

>>876には
>・ここで扱っている受信メッセージ組立て処理の場合、
> メッセージ組み立て中の状態でreadが0を返せば、
> それは通信障害によるコネクション切断と判断する
下位レイヤーが、上位レイヤーがメッセージ組み立て中の状態である事を知ってるっ
て書いてありますが。www
883デフォルトの名無しさん:2014/06/20(金) 17:48:20.00 ID:JSi28Lkj
バカからかうのも面倒くさくなってきた。

メッセージ境界が保存されないTCPでも
write(s, &v, sizeof(int));で書かれたvは
read(s, &v, sizeof(int));で読める。全然問題ない。

問題あると騒いでるバカはすべてのプログラムのreadをと書き換えろ。
(sがソケットになる可能性が0ではないから)

int nread(int s,char *buf, size_t sz)
{
int cc, l;
for (l = 0; l < sz; l += cc)
if ((cc = read(s, buf + l, sz - l)) < 1)
return 0;
return l;
}
884835:2014/06/20(金) 18:28:03.97 ID:fiYVjyLm
>>880
いや、通信障害という業界用語は、データリンク・レベルのエラー(回線障害)から
アプリケーション間プロトコルのエラーまで、幅広いエラーを含んでいる
そして>>876で書いたように、システムコールが正常終了しても
通信サービスとしてはエラーとして扱うケースもあるから、
read/recvのリターン値 -1 だけでは、すべての通信障害を検出できない


>>881
わかった、では自分は落ちるから、後の >>883(ID: JSi28Lkj)の世話、よろしくたのむ


>>882
君への最後のレスを返す

受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
2個のモジュールがあるという構成を理解できていないのかな?
これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
885デフォルトの名無しさん:2014/06/20(金) 18:52:29.32 ID:fmtXRHPg
>>883
ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
返ってくるので0復帰してしまう
100点満点中10点だな
886デフォルトの名無しさん:2014/06/20(金) 20:05:21.58 ID:JSi28Lkj
>>884
> 受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
> 2個のモジュールがあるという構成を理解できていないのかな?
> これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
ぷぷぷっ また後付け。

> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
システムコール発行直後でエラー処理を行うとはっきり書いてあるわけだが。

>>885
最後だと言っときながら、余計な事書いて恥の上塗り。みっともないねえ。

> ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ねーよ。バカ。www

> ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
バカには分からないらしいが、ブロッキングI/Oで書いてあるのは一目瞭然。www
887デフォルトの名無しさん:2014/06/20(金) 20:12:22.25 ID:fmtXRHPg
TCP通信はキープアライブのタイムアウトが非常に長いから
ブロッキングI/Oでreadすると、通信遮断で返ってこなくなるよ
経験のなさがもろに出てるね
888デフォルトの名無しさん:2014/06/20(金) 20:15:02.16 ID:5fUr2YwO
blocking I/Oを使う時点で素人
とか言ってみる
889デフォルトの名無しさん:2014/06/20(金) 20:19:43.47 ID:JSi28Lkj
>>880
> 通信障害は-1が返ってくるし
はい、ダウト。 www

TCPの切断では-1は返ってこない。このバカこの程度の知識で偉そうにしてて大爆笑だわ。
890デフォルトの名無しさん:2014/06/20(金) 20:20:15.90 ID:nPXPLHY1
ID:JSi28Lkj が哀れすぎ。見ててつらい
891デフォルトの名無しさん:2014/06/20(金) 20:22:24.13 ID:JSi28Lkj
>>887
最後と言ってたのにやっぱり出てきた。バカ見苦しいぞ。www

> 無限に
> 無限に
> 無限に
> 無限に
> 無限に
892デフォルトの名無しさん:2014/06/20(金) 20:25:18.42 ID:OK+lAQ+1
ID:fiYVjyLm = ID:fmtXRHPg 説なの?
わっかんねー
893デフォルトの名無しさん:2014/06/20(金) 20:25:51.90 ID:9kUUzjJL
>>887
ちゃんとしたヤツならソケットオプションでタイムアウトを設定するでしょ。

>>888
blocking I/Oに複雑怪奇で挙動不審なスレッド実装
何も分かっていない素人ほど複雑な実装をする
894デフォルトの名無しさん:2014/06/20(金) 20:28:16.42 ID:JSi28Lkj
ID:fで始まるバカが複数いるとは思わんかったわ。w
895デフォルトの名無しさん:2014/06/21(土) 00:24:24.12 ID:mv9//OJ7
発端の>>761は非ブロッキングの話
そっから>>824,835,844,853,860と流れ
>>860はID:JSi28Lkj

>>886>>883で書いた処理は「ブロッキングI/Oで書いてあるのは一目瞭然。」
という墓穴を掘り
しかも
>>844
> if (read(s, &size, sizeof(size)) != sizeof(size))
> error();
>>883
> if ((cc = read(s, buf + l, sz - l)) < 1)
> return 0;

まだ何も理解していないらしい
896デフォルトの名無しさん:2014/06/21(土) 00:32:58.75 ID:q5PhIp9u
>>895
非同期とノンブロッキングの違いを知らないバカは引っ込んでいなさい。
897835:2014/06/21(土) 01:48:01.43 ID:nSPSSkcc
>>895
>>>860はID:JSi28Lkj

>>860カキコは、自分(>>853)のアンカ間違いが原因
>>860が間違いを指摘してくれたので、>>863で訂正した
898デフォルトの名無しさん:2014/06/23(月) 12:37:22.72 ID:XKl4yasN
>>893
TCPのタイムアウトはソケットオプションにないよ、
って思ったら、Linuxではちょっと前から追加になってるのね。
899デフォルトの名無しさん:2014/06/23(月) 13:07:02.22 ID:HIGf9m9i
SO_SNDTIMEO, RCVTIMEO はどこに効くのかよくわからん
900デフォルトの名無しさん
>>899
それぞれ送信、受信のタイムアウトだよ