1 :
デフォルトの名無しさん :
2012/10/31(水) 17:05:08.29
ではご相談を受け付けます。 最初の方、どうぞ。
最近、なんだか元気がなくなってしまって・・・
その手のしまりのない肉塊を見ると、吐き気がするんだ・・・
>1000 インターネットを創ったのは LinuxじゃなくてBSD これ豆な
>>12 「インターネット」じゃなくて"Internet"
これまめな
>>13 "Internet"じゃなくて"The internet"
これまめな
BSDが作ったのはインターネットじゃなくてアーパネットじゃね?
>>14 "internet"を挟むんだった、残念
BSDが作ったのはSocketインターフェース
最初期のインターネットにUNIXはあまり貢献してないです。 1980年くらいになってようやくUNIX上のサーバ実装が定着してきました。 それまでは370とかSDSとかPDPとか。
Linux(CentOS6.3-x64)でルーティングをいじってて気づいたのですが 自身からルーティング不能なIPアドレスからパケットを入力した場合 OSにはパケットは届いても、プロセスまで到達しないようです。 OSが自身からルーティング不能のホストからの入力の場合には捨ててそうだ というところまでは分かりました。 でもパケットそのものはせっかく届いているし プロセスが受信できても良さそうなもんだな、と思ってしまいます。 この破棄動作は何か意味、というか意図が含まれているのでしょうか?
20 :
19 :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) とか。
>>19 自分宛のパケットか判断する前の話?後の話?
RPFじゃないの?
ちょっと違う話かなと思うけど良かったらお願いします DNSの安全性をチェックするプログラム書きたいんだけど基本的に問い合わせクエリに対するレスポンスを解析して安全性の基準と比較するって形なのかな
DNSの何の安全性?
基本的に外部からの脅威(キャッシュポイズニングとか)に対する安全性ですかね 例えばDNSサーバが再帰クエリを返すかとかポートがランダムかとかの判断をさせることになるはずだと思います 既にこういうサービスは結構あるといえばあるようだけど… アクセスしてきた人の使ってるDNS判定してそこにチェック用のクエリを送ってそのレスポンスで判断という流れになるのかなって 安全かどうかの基準はRFCをよく確認する必要がありそう
何が質問したいのかわかってない質問者に何を答えろと?
DNS関連のRFC読んでたらそれだけで3ヶ月はかかると思われ
>アクセスしてきた人の使ってるDNS判定して そんなこと出来るのか すげー
29 :
デフォルトの名無しさん :2012/11/02(金) 11:32:27.60
質問の趣旨も理解せずに主義を語るのが病気持ちプログラマの特徴
DNSのポートってランダムなの?
31 :
デフォルトの名無しさん :2012/11/02(金) 12:09:35.16
>>30 送信元ポートをクエリごとにランダムにすることで攻撃の成功率を下げる意味がある
>>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 |:::::,イヽ:又 ̄ヽ' ::::::::│ |:/ ゝヽ∨/' ヽ::::::│ / ヽ:|
libnetlinkについての日本語の情報(ブログ,本等)ないかなぁ. スレチか...
>>22 どうやら当たりでした。
なるほど。ありがとうございます。
漠然とした質問ですので、適当にアドバイスお願いいたします。 これからモバイル(スマホやタブレット端末)相手のソフトを作ろうと考えています。 アプリは社内システムの延長です。 社内システムはC++BuilderとSQLServerでシコシコ10年以上やってきました。 なんだか浦島太郎みたいなおじさんですが、いろいろ調べてAdobeのFlashBuilderで やるのが簡単そうだ、ということで使用ライセンスを得ました。 で、端末相手のサーバーはどうする? ということでC++Builderに付属のIndyコンポーネントを初めていじっていけそうな感触を得ました。 スレッドを意識しなくても書けそうです。 しかし、ここから進みません。 どういうプロトコルで上位のデータのやりとりをするのが合理的かということです。 WebサービスだのSOAPだのちんぷんかんぷんです。
Flashはオワコン
やる気がありませんと言ってる奴に何をアドバイスする事があると言うのか
HTTPベースのサーバアプリ書いてもいいし、TCP/IPベースの独自サーバ書いても何やってもできそうなもんだが。 おじさんになると、検索もできないし、書店に行くこともできなくなるのか。やだやだ。
>>40 最初はその独自サーバーで行こうかと考えましたが、
もっと定型的で簡単な方法があるのかなと調べている途中でした。
昔のDOS時代にもモデムを使って独自のフォーマットで
やりとりした事があるのですが、あんまり練った仕様じゃなかったので
簡単な拡張もできなかった経験があります。
どうもお騒がせしたしました。
>>42 > 最初はその独自サーバーで行こうかと考えましたが、
> もっと定型的で簡単な方法があるのかなと調べている途中でした。
「独自サーバー」の通信部分は定型的で簡単に書けます。
誰が書いても、通信部分はまあ似たようなものになるでしょう。方式は何パターンかありますが。
要するに、Socketを使ったサーバアプリを書いたことないってだけでしょ。
> もっと定型的で簡単な方法
が、HTTP上にのっけるアプリなんですが。
どんな言語でも"Hello, World!"を返すぐらいのレベルなら、すぐに作れるでしょう。
HTTPを返すのが嫌なら、JSONを返したり。
> いろいろ調べて
いや、調べてないでしょ。あるいは壊滅的に調べるのが下手とか。
本屋行きなさいよ。
浦島じいさんなのだろう
これが後釣り宣言という香具師か
>>43 どうも、ありがとう。
あれからFlash Builderの側(クライアント)を調べたら素のTCP/IPの選択肢はありませんでした。
HTTP、PHP、XML、Webサービスとあと聞いたことないやつ3点のどれかです。
お粗末さまでした!
もう、自分が何を言ってるのかもわからない状態。
初歩的な質問かと思いますがよろしくお願いします。環境はWindows7, Visual c++2010です。 proxyサーバー越しにネットワークに接続するにはどうすれば良いでしょうか。 現在は、単純にSOCKETを作って、サーバーにconnectしてGET メッセージを送るという方法を使用しています。 しかし、今後はproxyサーバー越しに、ネットワークに接続する必要が出来ました。 proxyサーバーを介する場合、接続先サーバーをproxyサーバーにして、本当に接続したいURLをGET以降に 記述したらいいということまではわかりました。 しかしユーザー名とパスワードの必要なproxyサーバーのため、usernameとpassをどのように設定すればよいか 解りませんでした。 ユーザー名とパスワードを入れずにそのまま接続すると、やはり HTTP 407 が帰ってきます。
プロキシサーバを構築された方に相談して下さい。 第三者には認証の仕組みが解らないのでアドバイスが困難です。
>>49 IE とかなら接続できるんでしょ?
なら、wireshark とかでパケット見ればいいんじゃね。
rfc 2617 を読め、とマジレスしてみる。
生データからアプリケーションプロトコルをデコードしたいんだけどよくわからない クラスでプロトコル定義するのにどういう風に設計したらいいのだろう 単純にunpackして分割してみたりはした
おーい、エスパー
無理!
エスパーじゃないけど, 挑んでみる > 生データからアプリケーションプロトコルをデコード 暗号買得と一緒で, パーターン解析して頻度計算すれば 運が良ければヘッダーくらいは抽出できるかも知れない > クラスでプロトコル定義する インタプリタパターンってのが王道らしいぞ yacc とか bison とか(じゃなくてもいいけど, オートマトン ジェネレータ的なもの)使えばもっと楽できるかも おそらく, 全然, 別の話なんだろうな w
エスパーとかいうまでもなく言葉通りパケットの生データから中身を解析するって話だろ tcpdumpとかwiresharkみたいに オブジェクト指向の言語で同じことするのに設計というか実装するのに悩んでるんじゃないの?
買得w
区
上ミス IOCPでUDPの送受信って出来ないのかな ネットでサンプル探してるがTCPしか見つからん 自分でいろいろ組んでみたんだけど送信した後にGetQueuedCompletionStatusがエラー返してくる 受信する相手がいる場合はエラーにならない。相手がいない場合だけエラーになる。 もしかしてTCPみたいに接続が確立されてないと使えないのかな?
>>60 できる
ソケットのみで送受信できるようにbindしておくよろし
OSはまあ関数名でわかるけど、 (AIXもIOCPはあるんやで) どんなエラーか書いてね。 それから相手ポートが閉じてる時にどうなって欲しいの?
受信もしてるからbindはしてる 返ってくるエラーはERROR_PORT_UNREACHABLE 相手がいてもいなくても、ただ単純に受信待ちしつつ周期でデータ送りたいだけ
port unreachableならTCPでも同じ。 コード書いてリトライしてください。
そうかー。とりあえずエラー無視して続行しても大丈夫みたいなんだよね。 IOCPのハンドル閉じるまで処理巻き戻しとかしなくていいんであれば無視でいいかな・・・
ローカルなファイルへの書き込みをするときのように write(client)からclose(client)の間にfflush(client)をするべきでしょうか?
そうまでして省く必要があるのか?
close()はflush()もしてくれるだろ
そもそもsocketにbuffer flushは無いだろ 気にせせずcloseして帰り値は捨てて良い ネットワークアプリケーションは信頼性が低いというのは、知識に欠けるユーザーでも信頼性が低いと知ってるから、エラーがでてもあまり気にしない
>>69 >気にせせずcloseして帰り値は捨てて良い
こういう奴が作るネットワークアプリケーションの信頼性は低いんだろうな。
すいません 結局のところバッファの掃き出しはどうすべきなんでしょうか?
プロトコルで終わりが決められてるんでもなけりゃ いくらフラッシュしたところで閉じるまでにまたデータ来るかもしれんし 閉じる必要があるときに閉じるだけでいいだろ。
73 :
デフォルトの名無しさん :2013/01/13(日) 16:49:39.38
気になるならするべき
>>72 > いくらフラッシュしたところで閉じるまでにまたデータ来るかもしれんし
意味がわからん。
ひょっとして受信側で flush するとかしてるのか?
その前にflushするAPIなんてあったか?見たこと無いぞおれ
flush する API じゃないけど, setsockopt で SO_LINGER と TCP_NODELAY を突くくらいかなぁ
あと, 到達確認的な意味だと 送り側 shutdown(..., SHUT_WR) | v 受け側 if (read(...) == 0) { shutdown(..., SHUT_RDWR); } | v 送り側 if (read(...) == 0) {shutdown(..., SHUT_RD); } とか, かなぁ
クライアントのソケットで、同じポートに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));
ok
>>78 TCPのstremは、
<src addr, src port, dst addr, dst port>
の四つ組で識別される。つまりひとつでも違えば別のstream。
ひょっとしてTCP/IPの勉強をしても socketプログラミングにあまりはやくに立たないんですか?
役に立つわ
甘利早くも役に立たない。ちくしょ〜ユーロ円が台無し
>>82 TCP/IPの知識が無ければ、Socketを使ったTCP/IPプログラムでトラブルが
発生したときに、原因を究明することは出来ないだろうな。
他人の通信の傍受ってどうやるんですか?
サブネット内ならARP PROXYでトラフィックを誘導する
てst
2chのdat読み込むとトリップ付けたときの名前が</b> ◆wSaCDPDEl2 <b>のように<b>タグで囲まれてるんだけど 普通<b> ◆wSaCDPDEl2 </b>じゃないですか? なんで逆になってるんですかね?
</b>したいからです。
名前は<b>タグで太字表示になっている。 トリップは標準フォントになっている。 で、名前をつけないでトリップだけつけるから名前の<b>タグを 閉じるために頭に</b>がつけてあるんだと思われる。
なるほど わかりましたありがとうございます
マイiPhoneからのみアクセスを許可したサーバーを構築したいのですが マイiPhoneを識別するにはどうすれば良いとおもいますか?
つ認証
証明書を発行してインストールする
sslでユーザ証明書に途中からする時って脆弱性なかったっけ。
104 :
102 :2013/01/19(土) 21:46:04.98
>>103 CVE-2009-3555 SSL renegotiationによる脆弱性のこと。
apache2.2ではSSLInsecureRenegotiation onにしとかないと、あるディレクティブだけのユーザ証明書使えなかった。
このオプションはInsecureとあるように、脆弱性を受け入れられる場合しか使えない。
今、どうなってるのかは知らない。
>あるディレクティブだけのユーザ証明書 この考え方自体がSSL/TLSに対する挑戦だな
106 :
102 :2013/01/19(土) 21:58:42.35
>>105 どこでもユーザ証明書を要求してれば問題なかったのかな?
とっくに直ってるか。
Changes with Apache 2.2.15 March 5, 2010
SECURITY:: CVE-2009-3555
やけに古い話だな。 RFC 5746に対応してない糞クライアントなら今も問題になりうるが、 元のお題が個人利用だし想定する必要はない。
108 :
102 :2013/01/19(土) 22:36:58.74
>>107 その仕事しに客先行ったのは最近なんだけどなwセキュリティパッチくらいあてて欲しい。
ローカルホストのアプリが送信してるデータ、たとえばブラウザのGETメソッドとそのヘッダーとデータ見てみたいんですが ブラウザのプロクシをローカルホストに設定するなどしないと不可能ですか? プロクシを設定するないアプリの通信を監視するにはどうすればいいんでしょうか?
wiresharkとかでみれば?
>>109 UAみたいだことかなら、ncで適当なポートにサーバ立てて受け付ける。やりとりが見たい時はwiresharkかtcpdump。ncがteeみたいに使えたら便利だし、既存なのかな。
>>110 ,111
ありがとうございます試してみます
まだはじめたばかりなんですがネットワークはデバッグが大変ですね
>>112 キャプチャで簡単に全部見えるのだから、標準的なデバッガのない内部バスなんかより良いと思うのだが。
114 :
デフォルトの名無しさん :2013/01/21(月) 08:29:05.87
禿
Wiresharkで特定ポート宛のTCP SYNを捕まえて処理するDissectorを書こうと しているんだが、"tcp.port"のDissectorTableに登録してもESTABLISHED以降の パケットしか届かない。 SYNを処理するには"ip.proto"に登録して自分でポート番号を判断するしかないんだろうか? もしそうだとして、TCPヘッダのデコードも自分でやらなきゃならないのかな。
ごめん、勘違いしてた
118 :
デフォルトの名無しさん :2013/03/25(月) 14:31:30.15
TCPで100バイトのデータを送ろうとしています。 50バイトを送ったところで回線に不具合が起きて自動的にセッションが張りなおされました。 この場合、データの続きは51バイト目から送られますか?1バイト目から再送されますか?
どこまでACKもらったかによるのでは
つまりACKを送る前で切れてると でもACKって回線が切れる前に送ったかどうかわからないよね??
あ 反応無かったら何度も送るか つまり51バイト目からになるのかな
間違えたわ ACKは古いセッションに送るのか 新しいセッションはどこまで送れてるのかわからないのに51バイト目から再開してくれるのかな??
不明な時は前から送るだろうし、受け取った方は同じもの2つ受けても 大丈夫なように動作するだろう。
セッションIDって通信内容に含まれてるの? じゃないと前のセッションがどれかわからないよね?
どのレイヤーの話なの?
126 :
デフォルトの名無しさん :2013/03/25(月) 16:40:27.67
初心者すぎてよくわからん 途中で何かトラブルがあった場合、別のポートから続きが送られてくることもあるって理解で合ってますか?
そのポートってのは何だよ
>>126 あってません
もういちど、自分の手で、続きを送れ
サーバと一般のPCの間のインターネットの通信で 回線が不安定になっても自動的に繋ぎなおされることは無いってこと?
TCPの中の人が何を何度再送してようと、それはアプリから見えない水面下のことなので、気にする必要ない 100バイト送ったなら100バイト届くし、その間にポートが変わるようなことはない TCPの中の人がギブアップするようなトラブルが起きたら、切断されてエラーになる そのようなエラーが起きたときは、自動的に接続が貼り直されることはないし、自動的に別のポートから続きが送られることもない
それだ ありがとうございました
スゲーとか言うなよ情け無い
じゃあ繋ぎっぱなしのTCPってクライアントにIDを割り振らなくてもセッションから個人を識別できるってことか
せめてネスペを取ってから来て
そんなんじゃ NHN に雇ってもらえないぞ
最近はTCPのGraceful Restartができるらしいが。
139 :
デフォルトの名無しさん :2013/03/25(月) 22:07:05.43
MMORPGの作り方についての質問はここでいいですか?
ゲ作板のほうがいいんじゃないかね
あそこ過疎だし厨房しかいないし機能してないじゃん 板名に「技術」って付いてるけとその実態は技術板じゃなくて企画板じゃん
ってことはここでいいってことだな
>>142 まぁ、MMOのネットワーク限定ならな・・・
144 :
デフォルトの名無しさん :2013/03/26(火) 20:25:12.04
質問ですMMORPGの通信はどうやってやってるんですか?
本屋さんにそういう本が売ってるから買ってきなさい アマゾンでも楽天でもいいぞ
147 :
デフォルトの名無しさん :2013/03/29(金) 22:10:35.43
ここの住人は、メールソフトは既存のソフトを使うのか。あるいは、 自作するのか。その辺が知りたいな。
>>147 > メールソフトは既存のソフト
ユーザーエージェントのことでOK?
だったら, 既存のものを使う
# 自分用にカスタマイズできればそれでOK
MUAならwl使ってるわ。
>>147 既存のソフトで事足りるから既存のソフトを使ってる
それに通信部分は余裕でもメーラーとしての便利な各種機能を実装するのが面倒
アドレス帳とか、メールの検索とか、自動振り分けとか、etc...
一つ一つは実装しろって言われたらできるけど、全部実装するのは面倒
昔はmew, 今はgmail。 どっちもelispとjavascript(browser addon)でカスタマイズ。
152 :
デフォルトの名無しさん :2013/03/30(土) 16:52:03.33
gmailとか解析エンジンが中身読んでるから嫌だよ
>>152 メールを読まれてる可能性はどこも一緒だから
それを懸念するなら母数が多いところのほうが安全だろ
暗号化しろよ
>>153 母数が多いところを選ぶのは安全だが
選ばないという手もある
そんな俺は自宅メールサーバーを立てたよ
相手側のサーバーは避けられないからそれは仕方ないけど、母数とかって話が出たから確率論でいくと、
「どちらか一方のサーバーで解析される確率」より
「相手のサーバーで解析される確率」のほうが必然的に低いわけだから
後者の自宅サーバーのほうが安全
自宅メールサーバーマジオススメ
アホだな。
158 :
デフォルトの名無しさん :2013/03/30(土) 22:13:30.88
>>155 何を言っているんだ。
サーバで見られること気にしてるのに、サーバで、またはサーバとの通信を暗号化しても意味ないだろ。
S/MIMEとかMUA間でメッセージを暗号化するんだよ。
>>158 このスレの住人ならドメインと自鯖くらい持ってるだろ。まあセカンダリを分けるとなると大変だけど。
>>159 メールを暗号化してもPGP作った人みたいにFBIに追いかけられませんか?
162 :
デフォルトの名無しさん :2013/03/31(日) 12:01:43.31
>PGP作った人みたいにFBIに追いかけられ どういうこと?w 詳しくw
輸出規制の制度の隙間を縫って輸出するような真似をするからだよ。 書籍は規制対象外なのを利用して、本として持ち出して、 スキャナで取り込むとかしたんだっけ?
UDPを利用して特定のポートにデータを送信する場合、 受信者がいなければ、行き場を失ったデータはどこへ行くのか? 一定数はキューみたいなものに保存されるのかしら? それとも逐一消えていくのかしら? 前者の場合、リアルタイムシステムに悪影響を与えてしまうと思うけど、どうなんでしょう。 初心者でスマソ
初心者お断り
>>165 受信ソケットの話かルータのIPの話かわからないが破棄すればいいだろ。いないってなんだ。
申し訳ない、ソケットの話ね。 "1"というデータを送信、250msec待つ 次は"2"というデータを送信、待つ … という送信プログラムと、 特定のポートにアクセスしてデータを所得するプログラム を書いてみたんだけど、送信プログラムをしばらく走らせてから受信プログラムを走らせても、 すでに消え去ったと思われる1というデータを取得してしまう。
icmpってのがあるが、 icmpで反応があることを期待してはいけない。 相手が生きているか死んでるかはっきりしないのが分散システムの基本。
>>168 本当に受信者居ないの?
もしかしてパソコンの電源が入ってない?
>>170 送信相手がいないと確定してるときって送信しないんだっけ?
UDPは気にせず送信しちゃうんじゃないの?
プログラムがどこでブロックしてるか確かめながらやってみそ
>>171 気にせず送信すると思う。
>>172 プログラム側に問題があるのかな…
OS側のバッファのせいとしか思えない…
>>173 試しに1じゃなくて送信時刻を送ってみては
全てが正しく動いているなら、ICMP port unreachが送信したホストに返る
自己解決しますた… 受信プログラムを待機させている間にソケットにポート設定をしてたのが原因みたい よくワカンネ
>>178 ふざけんなよ!
>送信プログラムをしばらく走らせてから受信プログラムを走らせ
って書いてたよな? 適当なことを書きやがって
ポートをバインドした時点で受信は開始されます
カーネルにバッファされます
ワロタ
プロトコルスタックさんの気持ちになって考えればすぐにわかることだろうに なにが「よくワカンネ」だ
馬鹿は馬鹿とは自分では認識できないということだな
ほしゅ
久しぶりにwinsock使ったら面倒くさかった。 ここ数年C#にどっぷりつかってたから、C++でコーディングするのが面倒だった。 実行環境のことを考えなくてよいなら、C#やJavaで作る方が簡単だな。
JavaはHttpURLConnectionで事足りるレベルなら簡単だけど Socket作るんだったらたぶんC#のほうが簡単そう。
質問ですが select(2)の第一引数には結局何を渡せば良いのん? バークレーソケットの場合、FD_SETSIZEを渡しとけば機能的には問題無いらしいが、 これは例えばFD_SETSIZEが32768の環境なら、select()を呼ぶたびに 32768個のディスクリプタがチェックされることになるので無駄が生じている気がする… あとWinsockではFD_SETした個数を渡せば良いというのは本当ですか
188 :
187 :2013/06/01(土) 23:24:31.90
一番大きいfd+1
190 :
187 :2013/06/02(日) 00:00:57.31
>>189 レスdクス、
select(2)を呼ぶ時点でFD_SETされているのはソケット番号であってディスクリプタ番号ではなく、
ソケット番号がディスクリプタ番号と一致するとは限らないと思うのですが、それでも?
実はバークレーソケットでは一致するのでしょうか
(C標準ライブラリのIOBとかの実装と同じで、
ハンドル==配列の添え字、とする実装のが自然とは思えますが、仕様としてどうなの?)
socket(2), open(2)が返すのはfd。 fdは全部数字。 「ソケット番号」という概念はない。
>>191 レスdクス多分理解しました
バークレーソケットの場合は全部fdなので問題は無い、と、
ただ、サーバ側のプログラムでは、クライアントから新規接続cがあった場合、
listenしていたfdをaccept(2)に渡して接続c用の新規fdを取得する結果、
select(2)で待つべきfdが増殖していくと思うのですが、
ということは<一番大きいfd+1 >というのはそのつど更新していくもの?
それとも、通信プロセスを起こすタイプのマルチスレッドサーバにすると問題無い(普通はそうする?)のでしょうか…
あと関連質問なのですが、
通信「スレッド」を起こすタイプのマルチスレッドサーバではどうすれば良いのでしょう…
子プロセスにfdを渡すのと異なり、親がfdを閉じるわけには行かない
しかし親だけがselect(2)するのでは通信「スレッド」を起こす意味がない
また、実情はともかく、仕様上はWinsockはスレッドセーフとは謳われていない
(Winsock互換の非スレッドセーフな実装が理論上は有り得る)
ので、どうプログラミングするのが正しいのかいまいちわからん…
そりゃ更新しないと意味ないわな。 マルチスレッドサーバならselect(2)は使わなくていいでしょ。 いろいろな混合モデルもあるけど、最初は簡単なモデルで。
何バイト送られて来るかわからない通信でselect→1バイトずつreadと言うのはやるべきじゃないってmanに書かれてたけどどうするのが一番効率的なんでしょう。 mtuの値を取得してその値-フレーム分をreadするのでしょうか?
そりゃ 1MB 受け取るのに百万回繰り返さなきゃいかんようではお世辞にも効率いいとは言えまい ノンブロッキングモードにして適当に大きなサイズ (8KB とか 64 KB とか) で読めばいい
ノンブロッキングにする必要はない。
selectしているのはブロッキングさせたくないからで、selectの後に受信データより多いバッファ分読み込もうとしたらブロッキングしちゃうからノンブロッキングで読み込む方が良さそうな気がするけど何か見落としあったりします?
> しちゃう ダウト
ブロックするだろ
しないだろ
1バイトでもデータがあればね
select後 受信データが1以上でバッファはデータ以上の大きさで読み込むと? 受信データが無いのに読み込むと?
206 :
デフォルトの名無しさん :2013/06/03(月) 11:33:03.05
馬鹿じゃなかと?
ゴカイうまかっちゃ
むろみさんは海に還れ
あんたドライバー刺すわよ
210 :
192 :2013/06/08(土) 23:51:12.09
211 :
192 :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のやり方は古い疑い有り)
何言ってるか分からないが、その現代版サンプル(謎)でも fd + 1 になってるじゃねーか
>>213 何を言いたいのか分からない
FD_SETSIZEを超えたらまずいというのならその通り。
下のURLの方は、
>> if (s[smax] >= FD_SETSIZE) {
でFD_SETSIZEを超えるものを除外してるから、
s[smax]がFD_SETSIZEを超えることはない
離散的だのベクターだのは意味不明
>>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の下のリンク先では、第一引数に書かれている内容が異なるのですじゃ
216 :
215 :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となった
217 :
214 :2013/06/09(日) 17:26:56.22
一応「何が」について答えておくと、ファイルディスクリプタ番号。
fd_set構造体をオーバーランしたらまずい、という理解で合ってる。
>>213 の上の引用と下の引用の第一引数は同じなので、何言ってるかわからない。
>>211 > socket()が返した数値(FD_SETSIZEより大きく成り得、かつ離散的)を配列かvectorにでもとっておいて、
> その値を直接与えるのが正しいっぽい
> 上の現代版サンプルでもそうなっている(つまり>189のやり方は古い疑い有り)
根本的に理解してないな。
>>189 と同じ事を言っておいて、古い疑いありとはw
仕様と仕様を満たすための実装方法の区別がつかない人みたい。
実装方法で考えないと仕様が理解できない。
私はselectは使わない、絶対に。
絶対ニダ
>>217 >>218 はいはい御託は>189をWinsockで動かしてから言ってね&#9825;
BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無いから>189のコードで良い
0〜FD_SETまでの中に、必ずsocket()で作ったlisten中のソケットがある
Windsockでは違う
>>221 > Windsock
ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?
つか,
> BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無い
保証は何処にある?
FD_SETじゃなくてFD_SETSIZEの事言ってるんだろうけど そんなもの使うのヤメレ
保証されてるのはFD_SETSIZE未満の記述子に対してだな。
しれっとウソつくなよ。
>>221
>>222 > > Windsock
> ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?
違う。似て非なるもの。意味不明の改変もある。
windsockってなんだwinsock2のことかね
別物なんだよなあ…ところどころ似てるけど全然違うから紛らわしい
質問です。 Winsockを使っています。 一度通信を終えた後に再度通信を行おうとすると、sendをacceptが認識してくれません。 bind,listen関数は正常に動作しています。 クライアント側は完全に再起動、サーバーはwhileで使いまわしています。 原因に心当たりのある人教えてください
>sendをacceptが認識してくれません 認識するわけなかろう
232 :
230 :2013/07/03(水) NY:AN:NY.AN
>>231 済みません。仰る通りでした。
connectの戻り値は0でクライアント側は繋がっていると認識しているようです。
サーバー側を消すとエラーが出てくるので間違い無いと思います。
サーバー側はacceptを使っているスレッドを消していない時は2つ以上の接続であっても、上手く動作します。
クライアント側が再接続する場合もちゃんと動きます。
しかしスレッドを再起動した時には一つ目の接続から認識しません。
変数は毎回初期化しています。
サーバーはwhileで使い回してるのにスレッドを再起動? 状況がよくわからんな
closeし忘れ?
listenしなおしってなんだよ しっぱなしでいいだろ いちいち再listenとかどこのBASICモドキだよ
accept に渡してるソケットを accept の戻り値で書き換えてるとか? accept の戻りのソケットは 接続発生毎に別物だから 変な使いまわしからすると 「接続は受けた けど クライアントとの通信が出来てない」 ってなことになる
238 :
230 :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();
}
}
これは肝心なところを隠して、どうでもいいところだけ書くダメな質問の典型だな 全体に意味不明だから、もう少し勉強してから出直すほうがいいと思う
ほとんどのバグは本人が関係ないと思って端折ってるところに存在する そもそも肝心なところがどこか判ってるプログラマはむしろバグらない
なんでこうセンスの無い人間がプログラミングなんかやるのか すべて駆逐したい
9割5分くらいのPGが消えてしまうじゃないか
104期生ってどのくらい巨人になれるの?
web(HTTP)の普及のせいで ネットワークを利用するアプリの質が極端に下がった 退化しまくり
なんでもWebサービス。まあ便利だけどね。
246 :
デフォルトの名無しさん :2013/07/10(水) NY:AN:NY.AN
webサービスは機種依存性をなくしたりアプリのインスコの手間を省いたりDLL地獄回避のメリットがあると言われていたが 結局ブラウザのバージョン依存で地獄とか同じ過ちを繰り返してるとしか
俺の言ったwebサービスはWebブラウザは関係ないけどね
248 :
デフォルトの名無しさん :2013/07/10(水) NY:AN:NY.AN
P2P掲示板の同期方法はどうやればいいですか? 基本が一対一の通信なのに全体で同じデータを受け取れるのはむずかしくないですか?
通信速度が上がったから、HTTPのオーバーヘッドが気にならんからなぁ
>>248 P2Pで全体ってどういう事を言ってるのかしらんが
全体で同じデータを受け取る必要はないだろ
WebサービスってWSDLとかの話だろ、ブラウザ関係ねえw
251 :
デフォルトの名無しさん :2013/07/10(水) NY:AN:NY.AN
ソケットでhttpクライアント作ってみたけど意外に簡単すね でも企業面接でhttpの質問のみで落とされますた
java の質問で拾ってもらいました10年前
TCPのパケットの問題で落ちたわ…
>>248 難しくは無い。
全体に同じデータを送る必要があるなら、全体に同じデータを送るだけ。
非常に単純な話だよ。
>>255 tcp6に採用されるような論文書かないと説得力全くない。
特殊な状況でしか効率良くないプロトコルじゃあ...
TCPが効率悪く見えるのは通信が1対1のときのを測定してるからだよな 多対多の通信を想定したプロトコルなんだから
TCPって思いっきり1対1の通信を想定したプロトコルじゃねーか。
259 :
デフォルトの名無しさん :2013/07/11(木) NY:AN:NY.AN
故47氏がTCPを何十倍も超える高速通信を実現したとか聞いたが
TCPが回線スループットの何十分の1の速度しか出ないなんて事は無いから 言ってることが明らかにおかしい
UDPは一方向の無手順通信 無手順だから早いってだけでハマらんようにね
既存ファイル転送プロトコルに比べて大して変わらない性能で何のインパクトもなかった(当時)。
出たなMulticastTCPお化け!
SCTPのマルチホーミング構成をとっているときに クライアント-プライマリサーバからはHEARTBEAT の送信・応答があるんだけど、セカンダリサーバの ほうってプライマリからのハートビートインフォメーションに 乗せるんじゃなくてセカンダリサーバからHEARTBEAT 返すことってSOCKOPTのパラメタ設定とかで可能?
>>260 複数セッション束ねるとか、方法はあるでしょ
>>260 TCPはRTT依存するし、パケットロスに対する速度低下率が高すぎる。
無罪判決後、47氏の夢 2012年 『Winnyの金子氏が夢見る次世代高速ネットの世界』 ascii.jp/elem/000/000/712/712158/ >金子:本当にTCPがボトルネックなんですよ。みなさんあまり気付いていないですけど、 >SilverBulletで動作させてみると楽勝で10倍くらいの通信速度が出るんですよ。ヘタすると100倍くらい出ますから。
269 :
デフォルトの名無しさん :2013/07/12(金) NY:AN:NY.AN
TCPコネクションが <自IPアドレス, 自ポート番号, 他IPアドレス, 他ポート番号>という 組(tupple)でモデル化されることは、このスレ住人にとっては常識だと思う。 で、TCP層の利用者(user)であるアプリケーションの視点からは、 TCPコネクションは相手アプリケーションとの間の「1対1」関係に見えるし、同時に TCPコネクションの集合を扱うTCP層の提供者(provider)であるTCPスタックの視点からは、 自集合と多集合との間の「多対多」に見える。
ベストエフォート側のネットワークで、 みんな帯域を譲りあいながら使ってるわけだからさ、 じゃないとslow-startとか必要ないわけよ。
>>266 >パケットロスに対する速度低下
それは確かにそうだね
>>271 ふつう、全単射を「多対多」とは言わんわな。
言わないな
TCPを多対多とか言う奴はUMLの多重度も正しく書けないだろ
輻輳を意識したプロトコルなんだから 1対1のことだけ考えてる訳ではないよ
速度低下の原因が輻輳であるならば 1対1の場合なら速度低下は起きない と言っているということになる それではいったい47氏の主張と どこが違うと言えると言うのか
何が言いたいのか伝わって来ない
>281 頑張ったところを教えて
どっかのTCP/IPスタックがお馬鹿ってだけじゃあ
>>281 これは酷い
某技術書のサンプルコードとほとんど同じコードばかりじゃねえかw
WinSockで通信プログラム作ってるんですけど ポート1つで通信するとした場合 ホスト側でソケット2つ用意してクライアント2人と繋げたいんですけど どうしても片方のソケットにしか二人分のデータが飛んでこないんですけど どうしたらいいですかね
マヌケな発言はやめてくれ 力が抜ける
まず服を脱ぎます
このスレに来ていいレベルじゃないな
いつからこのスレがレベルの高いスレだったと錯覚している?
俺が来た時から
誰も高いなんて言ってないんだが...
>>289 安心しろ
君がいることがレベルが高くない証明だ
俺とお前と
田舎ではまだいるけど東京ではLooseSocksはほぼ絶滅したね。
>>294 へえ、じゃ今はどんなのがはやりなの?こっちは田舎(神戸)だからよくわからないや
いまはNoseFooksだな
自分からドナドナされにいくのか?
大五郎〜♪
おれとおまえと
だいごろお〜♪
>>282 ネットワーク通信ですかね
サーバーアプリつくれば3000コネクションぐらいだったらいけると思います
微妙だな。頑張ったと言うわりに10Kは特に意識してないってことか。
この業界は何かと3Kと言われますしね
>>302 テストは10Kでやってるんですが、まあユーザープログラムの実装を入れたらもっと下だろうってことで
長時間の安定稼働がきついんですよね
10Kコネクションで、最低でも一週間以上稼働し続けられるものを目指してはいます
で、それを実現するために何苦労したとか、 役立つことは一切語る気はない、ただの宣伝行為という認識でいい?
308 :
285 :2013/07/14(日) NY:AN:NY.AN
http://plsk.net/socket マルチスレッドにしている部分のソースコードはらせて頂きました。
(現在は10個このスレッドを作成しています)
UDP/IPでの通信で同一ポートの使用が条件で
複数のクライアントと通信したいのですが
2箇所から通信してもらっても同じソケットにしかデータが着ません。
ここで質問なのですが
@分けることは可能なのでしょうか?(ソケットひとつにつき一人にする)
A分けない場合1つのソケットに複数のクライアントからデータが飛んできますが
その様な動きはサーバーとしていいのでしょうか?
ソースは読んでないが、 同じソケットを使え エラー処理はちゃんとやれ
>>308 不可能、いい
#ソースコードの断片から滲み出る初心者臭が酷いな
bindのエラーコードチェックすればすぐに分かることなのに
312 :
285 :2013/07/15(月) NY:AN:NY.AN
>>309 >>311 書き直した所bindで最初以外の9つのソケットからエラーが出てました
エラー処理は大事ですねありがとうございました
>>310 1つのソケットでデータを受信することにします
ありがとうございます
C言語初めてもう5年近くなるのにひどいありさまです
ソース読んでなかった人間だけど、 ちゃんと文章で説明できてたからエスパー出来た。 それほど酷い有様でもない。
特定のポートを使用しているプログラムを全員殺す というプログラムはどうやって書けばいいかな
全員って?例えば?
>>315 たとえば、待ちうけや接続で ローカルポート9999 を使用している
プログラムを全員殺す
って fuser で一覧出して殺せばいいのか
ありがとう
全員って、一つのポートを複数のプログラムで使えたっけか?
使えますが?
socket APIで。 TCPの接続は<src IP, src port, dst IP, dst port>の四つ組で識別される。
>>320 複数のプログラムで使えるのは、src portの方?dst portの方?
そのとき、send()やrecv()ってどうやるの?
特定のポートに接続してくる迷惑な相手鯖を全員殺す というプログラムはどうやって書けばいいかな (迷惑の基準は一秒間に一定回数回以上とかです) ただフィルタするんじゃなくて相手側のプロセス(出来れば鯖ごと)殺したいです
自分の管理下じゃない、相手プロセスを殺すのは無理 案1) IPメモって 上位のところに abuse 報告 案2) 接続ポートを特定化しないようにする細工がかけられればそれで自衛
IP特定できてるならダミー鯖を用意してそっちに誘導かなぁ
>>321 せっかく
>>320 がTCPコネクションの概念を明解に書いてくれているのだから、
その意味を(ネットの情報や書籍を参考にして)勉強してみたほうがいいと思うよ
327 :
321 :2013/08/05(月) NY:AN:NY.AN
今までいくつもソケットを使うアプリを作ってきたけど、同じポートを使うという 発想がなかったから全く想像つかないんです。 同じポート番号でlistenするってことなの?
328 :
321 :2013/08/05(月) NY:AN:NY.AN
あ、ひょっとして、connectで同じポート番号を使ったプロセスをkillしたいってことなのかな? 今使ってるポート番号じゃなくて。
何寝言いってるんだか
どんな糞アプリ作ってきたんだよ?
ポート80を使用しているプログラムを全員殺す=世界中のWebサーバを殺すってことだろ。
apache MPMを調べてみると良い。コードも読める。preforkが分かりやすい。
俺もソケットよくわかんね 教科書通りだとforkして平行宇宙せよってなってるし 実際試してもそれで同一ポートでの通信が出来ちゃうんだけど 四つ組じゃそれぞれのクライアントを識別するのはどうやってんだろうって
難しいことなど何もないよ まずその教科書を投げ捨ててプログラミングしろ
シグナルとかが絡むとどうしたらいいかわからなくなる 例えばSIGPIPEが来たときreadしてるスレッドから来たreadの終了を表すものなのか そのほかスレッドでの要因なのか判断する方法とかわからなすぎる
WindowsSocketのGracefulShutdownを実装してSend側をshutdownしてから0が返るまでrecv呼ぼうとしたらそのままブロッキングしてcloseまで辿り着かないんですけど…
>>337 それほんとうにブロッキングしている?
ブロッキングと思い込んでるだけな気がする
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の差が開いていく 内部バッファ?の古いパケットは捨てて、 最新のパケットだけ使う設定とかないのかな?
>>339 録音再生なら、オーディオデバイスでのズレの蓄積が原因
昔某メーカから調査頼まれたやつで、ドライバのクロック設定に 明らかなバグがあって、周波数が1%以上もズレてるのがあったよ
そうじゃなくてもクロック偏差はどうしても存在するから 何らかの偏差吸収メカニズムがないと必ず破綻するよ
ASIMOに運んでもらうか
先行者で十分
ユーザーの心拍数に同期するようにしたよ
腕時計と人差し指・中指に決まってんだろ
看護師が言ってたが、あまりあれは正確さが欠けるのでやりたくないらしい
そういや最近bluetooth接続の心拍計があるな。ちょっと欲しい。けど一回しか使わなそう。
SNMP TRAPあげてくれる体重計とか無いですかね。 いちいち倉庫から引っ張り出して乗るのは面倒なので椅子の下に常に敷いておくだけで40キロ以上の重量が加わったら時刻と重量を定期的に飛ばしてくれるだけでもだいぶ助かるんだけどなぁ。
ときどき脈が飛ぶんだけど こんな私でも通信出来ますか?
めんどうだから 体重が2Kg以上増えたら電気ショックが流れるようにしたら
> 体重が2Kg以上 この業界では2Kgなんぞは誤差のうちって奴がほとんどじゃないのか?
>>354 一日で2Kg増えると考えると妥当と思うが
AIカーではシートが健康診断してくれるそうな(by TV)
医師法違反ですね
>>353 > 電気ショックが
この業界では電気ショックなんぞはご褒美のうちって奴がほとんどじゃないのか?
こうしてショッカーが誕生した
359 :
デフォルトの名無しさん :2013/09/19(木) 16:14:49.62
アイゴー
ケー
> 電気ショックなんぞはご褒美のうち ラムちゃん (;´Д`)ハァハァ
362 :
デフォルトの名無しさん :2013/09/21(土) 10:31:20.92
宣伝乙
>>362 これは面白そうなソフトだな
etherealと干渉しないなら使いたいな
365 :
デフォルトの名無しさん :2013/09/21(土) 17:54:15.50
ホシュ
366 :
デフォルトの名無しさん :2013/09/24(火) 03:26:25.19
>>352 俺もあるよ。徐脈性不整脈だろ。椅子の圧力でももの下側の血流が悪くなるのが原因だと俺は特定した。
デスクワークが多いPGの職業病ともいえる。びんぼうゆすりが有効。
>>366 ありがとう
スタバの硬い椅子でも長居出来るように
座布団持ち歩いてるんだけどなぁ
>>367 マーサージで血管を広げる、爪先立ちでかかとのあげさげ
だめなら病院行けよ(棒)
社長椅子みたいのに変えれば治るの?
ファーストクラス症候群
寝不足だろうな原因は
373 :
デフォルトの名無しさん :2013/10/28(月) 21:37:00.93
ソケットで、すでに送信元ポートがbindしてあるかどうかって なにで見るのが一番簡単かな
netstat
ニコニコ動画のコメントを取得するためにAPIを利用すればいいと思うのですが それ以外に方法ありますか?
376 :
デフォルトの名無しさん :2013/10/29(火) 13:55:49.85
selectで待つとき、 t.tv_sec = 0; t.tv_usec = 0; で無限に待つかと思ったらすぐ帰ってくるのな これ無限に待ちたいときは何セットすんだっけか
>>379 アイロンってシワを伸ばすアレだよね。
無線LANに自分で接続しない限り、認証が必要なんだし気をつける必要はないでしょう。
どちらかと言うと、干渉によるノイズが気になる。
近所でパスワードなしの野良APがあったら終わりw
あるよな いがいと たくさん
「一番つながりやすい会社」のだろう
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分
MSがインターネット接続の確認用に立ち上げてるdns.msftncsi.comを使う事にしました
自分の持ち物の回線・サーバを使って何が悪い。 公開されている鍵を集めて何が悪い。 お前のは他人の回線・サーバを悪用する犯罪行為。
391 :
デフォルトの名無しさん :2013/11/19(火) 09:50:48.03
途中の回線は他人の物だ
真正のキチガイなんだな、あーやだやだ 死んでくれないかな
>>391 そう思うなら、いますぐプロバイダ解約したまえ
>>391 インターネット批判とか、おまえどんだけ偉いの?
他人のサーバーをpingで攻撃してはいけません って言われないと、攻撃してもいい、と判断するのがゆとり世代。
396 :
デフォルトの名無しさん :2013/11/19(火) 09:57:11.55
経路を自社の製品のために利用するのは許されるという主張か? ターゲットホストに届かなきゃいいって事だな TTL 1にするからこれなら文句ないだろ
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攻撃企んでるアホがいる」と通報してくれ。
通報結果も教えてね。 はーと
何かいけないことなのかすら理解できていないんだな。
401 :
デフォルトの名無しさん :2013/11/19(火) 10:08:41.95
アホ 通報する方が迷惑行為だわ とっとと、通報しろよ
402 :
デフォルトの名無しさん :2013/11/19(火) 10:11:51.74
ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか 論理的に説明してみろ 出来なきゃお前の負けな
1ping/min位なら普通に自分のプロバイダのDNSにpingすりゃいいんじゃねーの? なんでわざわざrootサーバー使うんだ
後出しでttl 1になりました! ttl 1入りまーす!www
>>403 プロバイダに依存したくないからに決まっているだろアフォか
他の方法を取るべき事の代替にping使おうとしてねえか?
>>404 こういうことをするときの不文律だろttl 1は
はじめからそのつもりだったにきまってるだろ
言われるまで気づかなかった奴はネット使う資格はない
>>405 一言でもそういったのか?
なら決まってないと思うが
>>408 不文律だろ不文律
わかんない無能は氏ね
>>406 目的は企業秘密 実現手段として選んだのがICMP echo requestを投げる事
他の手段の存在は否定できないが、アホが集まる2chで質問する事ではない
他所の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は使い放題という事で契約している
お前の負け 引っ込んでろ
DNSの仕組みも知らないのか。
なにやりたいんだか知らないけど、 常識的には、ネームサーバもEcho受けるサーバも自前で設置するものだよ。 他人の資源を勝手に転用しちゃいけない。
釣り名目でひたすら他人を罵倒したいだけのガキだな TTL1ならどこ指定してもゲートウェイか近くで止まるんだから 固定する必要すらない 事前の想定をきちんと理解してるなら質問の意味ないだろ 知能指数測ってこい池沼
418 :
デフォルトの名無しさん :2013/11/19(火) 10:39:54.83
>>416-417 アホが必死で喚いても
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
これを説明できない お前の負け
やりたいことが、経路があるか知りたいとか、アドレスがあるか知りたい、 なのに対して、実現手段として基本的なソケットインタフェースしか知らない 無恥野郎なんだろうな
420 :
デフォルトの名無しさん :2013/11/19(火) 10:42:01.13
>>419 アホが必死で喚いても
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
これを説明できない お前の負け
企業の防壁によっては、管理者にアラートがあがるよ<ttl=1
blacklistに登録されてbangされるようになるとかそういう方向で解決されるんじゃね
IPv6はそもそもTTLじゃないという突っ込みはなし?
424 :
デフォルトの名無しさん :2013/11/19(火) 10:48:16.40
>>421 必死すぎる www
そこではtraceroute禁止ですかあ?
>>422 パケットが出ていかないのにブラックリストに登録とか 必死すぎる www
お前の負け
>>424 企業ネットワークでtracerouteを打つとか、普通に懲戒処分のところもある
無知すぎるぞおまえ
wiresharkやtcpdumpなどpromiscasモードアプリ=即検出、一発解雇 とかはよく聞く。
427 :
デフォルトの名無しさん :2013/11/19(火) 11:01:18.87
許可された特定のアプリ以外は使用禁止の企業もあるだろうが、 そういうところじゃないから作ってるし、そういうところでは使われない。 必死でひねり出した反論もアホの極致 惨めすぎるぞお前
そういえば10年くらい前にバカhub挿して端末増やしたら怒られたことあったわ
今時tcpdumpで盗聴なんてできないのに老害adminは死ねって感じ
最近の企業コンプライアンスは異常だからなぁ。 traceroute禁止とか聞いても、そうなんだくらいにしか思わん。 勝手にネットワーク障害を解決して解雇とかという話も事例として よく出てくるしな。
>>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に通報と騒いでたバカは逃亡したか? 通報結果を知りたいのだが
>>432 ノート型全盛で端末のネットワーク位置がどんどん変わるから
いまはまたarp spoofingに対応できない時代になっているんだよ。
ARPエントリが20分有効ってのがそもそもおかしいんだよな。 やりたい放題。
>>434 ステーション間の通信は遮断だろ 普通
そんな事も出来ないadminなら解任した方が良い
>>433 何一人で顔真っ赤にして盛り上がってんの?
いい加減空気読めよ
438 :
デフォルトの名無しさん :2013/11/19(火) 12:04:05.97
かいじせいきゅう
440 :
デフォルトの名無しさん :2013/11/19(火) 13:26:27.58
pingが攻撃 三菱電機インフォメーションシステムズの最底辺SEですら言わねーぞ
固有名詞出してんじゃねーよ非常識オレサマ野郎
年末特番「はじめてのつうほう」 撮影快調! 乞うご期待!
いやまあ三菱電機インフォメーションシステムズのやったことは犯罪に近いですしおすし知らないならググレカス
445 :
デフォルトの名無しさん :2013/11/19(火) 14:06:14.25
>>441 三菱電機インフォメーションシステムズの関係者?
あんなド底辺と関係あるって恥ずかしくない?
だからpingで通報とか言っちゃうのか
2ch来るような奴が知らないわけねえだろ いちいち見下す発言しかできねーのか屑
447 :
デフォルトの名無しさん :2013/11/19(火) 14:07:25.30
>>444 岡崎図書館事件を知らないドドド底辺がいるとわ
448 :
デフォルトの名無しさん :2013/11/19(火) 14:08:50.33
>>446 見下されたくなかったら、ド底辺な発言しないことだ
ping攻撃!!! 通報すべき!!!
で、TTL1のpingで何がしたかったのコミュ障
>>448 本気で同一人物だと思ってるの?呆れるわ
一人で盛り上がりすぎなんだよオナニー野郎
451 :
デフォルトの名無しさん :2013/11/19(火) 14:14:28.50
>>449 NDAで教えてやろうか?
公的個人認証で署名した秘密保持契約書アップしたら教えてやるよ
>>450 そういう事にしたいならしといてやるよ
>>451 NDAとか何背伸びしちゃってんの?ウケルー
つか、
>>385 > m.root-servers.netがこれに該当しますが、他にありますか?
他に探す理由は?
1 引けない場合に備える 2 選択肢は多い方が良い
aでもbでもcでも好きなの使え
他のルートサーバー使えばいいだけじゃん
8.8.8.8でいいんじゃないの?
>>385 企業ならいくつかのデータセンターにラック借りてるだろう
どれか適当な自社サーバー相手にping打てよ
459 :
デフォルトの名無しさん :2013/11/19(火) 15:00:52.23
ipv6.msftncsi.comってのがあった、v6はこっちにしよう
もう解決したんだから、後はブログでお願い。
もりあがってると思ったら、あらされてるのか 逆切れ--->あらしのパターンか
>>462 これ説明してよ
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
いい加減、別板か過疎スレでsage進行でやってくれ。
無差別に投げられるレス
ttlがなんだかわかってないやつが混ざっててわかりにくいぞ、進行が。
> ティーティーエル > TTL 【 Time To Live 】 > > パケットの有効期間を表す値。最大255までの整数値で表され、ルータなどを1回経由されるたびに値が1減少する。 > TTLが0になったパケットはその時点で廃棄され、廃棄通知がパケットの送信元に届くようになっている。 へー、はじめて知ったわ。
繰り返しになってきたな アホの相手も飽きたので この説明 > ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか または > m.root-servers.netを襲うかもしれないし、 > 通報しておいたほうがいいんじゃね? これの通報結果以外はレスすんな アホども あと、三菱電機インフォメーションシステムズのド底辺SEなら上記に関わらずレスしていいよ。
>>470 だから、aでもbでもcでも好きなの使えって
それ以上に何求めてんだよ
>>471 もうそれは終了してるから。www.msftncsi.com, ipv6.msftncsi.com
あとbはダメ 知ったかすんなよ
> それ以上に何求めてんだよ
↓かな 笑い
この説明
> ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
これの通報結果
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
うざ
>>472 > ttl 1のICMP echo requestを無差別に投げる事の何がいけないのか
いけなかない
> これの通報結果
多分通報した奴なんかいない
NDSがらみのことを2ちゃんねるで聞くとはぷげらちょ
>>475-477 お前ら、三菱電機インフォメーションシステムズのド底辺SEは生きてて恥ずかしくない?
きいてるきいてる
480 :
デフォルトの名無しさん :2013/11/20(水) 00:16:31.65
暴れるなら酉出せよチンカスども
iptables で許可されたパケットだけをダンプするコマンドはありますか? tcpdump だと全部のパケットが出て来てしまいます ><
tcpdumpは懲戒だと、三菱インフォメーションシステムズのド底辺SEが言ってた
483 :
481 :2013/11/20(水) 13:24:59.68
僕が懲戒になっても後に続く若人たちの踏み台になれるなら本望です おしえてください!!!
iptables と同じようになるようにオプションではじいたら
>>481 tcpdumpはフィルターの指定ができるだろう
まだいたのか・・本物だなこりゃ
こんなド底辺に出くわすなんて、1年に1回あるかないかだからね 早く通報してくれよ > m.root-servers.netを襲うかもしれないし、 通報しておいたほうがいいんじゃね? > こういう不文律が通じないアフォは徹底的に駆除するべき
>>487 お前がTTL 1だとあかしたレスを読む前にレスしたんだろうよ。
> 396 名前:デフォルトの名無しさん[] 投稿日:2013/11/19(火) 09:57:11.55 <- 秘密の暴露レス
> 397 名前:デフォルトの名無しさん[sage] 投稿日:2013/11/19(火) 09:57:58.97 <- 通報するぞレス
>>487 お前みたいなアホに出くわすのも、1年に1回あるかないかだわ
>>478 カジュアルにこんな毒吐いてると、いつか足下すくわれるぞ。
491 :
デフォルトの名無しさん :2013/11/20(水) 16:58:24.67
>>488 見てない証拠はねーし、pingを最大1パケット/1分は最初から言っていた
これでもいいから早く通報しろ
>>490 三菱インフォメーションシステムズはそれだけの事したんだから良いんだよ
むしろ風化させないために煽り続けるべき
相手するから居座るんだよ。 完全無視しろ。
この手のは嫌なら見るなするくせに、 トリップ付けろって言っても絶対付けないよな。
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を襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
>>484-485 ありがとう
-F オプションは判ったけど
iptables と書き方が違うので
ルールが沢山あって変換が面倒です ><
iptablesにログ機能くらいあるだろ、それ使えよ ド底辺
497 :
デフォルトの名無しさん :2013/11/20(水) 17:54:20.35
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分で 攻撃だ!! 通報だ!!! 駆除だ!!!! めったに遭遇できないド底辺
この粘着力 他でも荒らしてそうだな
503 :
デフォルトの名無しさん :2013/11/20(水) 19:42:10.19
ド底辺が発言どおりに通報して通報結果を報告すりゃ終了するんだが 言ったことは実行しろよ
俺俺プロトコルは通報パケットが発行されるまで終了せずリソースも開放しないと定義されております
恥かかせたいってことなら、 自分で通報して結果貼ればいいんじゃないの。 とにかく続けたいにしても別板でスレ立ててそこでやってくれ。
くやしいのうwくやしいのうw
507 :
デフォルトの名無しさん :2013/11/20(水) 20:25:53.27
>>397 みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
くやしいのうwくやしいのうw
509 :
デフォルトの名無しさん :2013/11/20(水) 20:29:10.20
酉付けろよキチガイ
m.root-servers.netを目的外に使うって言いだした時点で 完全敗北しているのに、いまだ生き恥をさらしているのかw くやしいのうwくやしいのうw
何がそんなに悔しかったんだろう? 最初からttl=1って書いておけば、こんなにもバカにされなかったネタだと思うんだがな。
くやしいのうwくやしいのうw
>>510 完全敗北という妄想はお前の半径3m以内でしか通じない不文律の話だろ。
くやしいのうwくやしいのうw
>>510 なんで?
公開サーバーなんだからping打つくらい問題ないでしょ。
いやなら公開するなよって話だ。
ttl=1で、最初から届かないことが確定でいいなら、 そもそも宛先はルートサーバーではなくてランダムアドレスでいい
他の人が同じことを始めたらどうなってしまうか、 考えられないのが山本太郎
518 :
デフォルトの名無しさん :2013/11/20(水) 20:57:34.97
>>516 だったらデフォルトルートがあるかどうかを見るだけでよくて
ttl=1以前にパケット送る必要自体がなくね?
くやしいのうwくやしいのうw
521 :
デフォルトの名無しさん :2013/11/20(水) 21:01:07.93
>>517 ttl = 1のpingを10万人位がm.root-servers.netに向けて一斉に打ちまくると、
どこにどんな影響があるのか説明してみろ ド底辺
くやしいのうwくやしいのうw
なんでまだroot-serversに拘ってるの ttl=1なんだから関係ないじゃん 説明してみてよ
525 :
デフォルトの名無しさん :2013/11/20(水) 21:24:11.51
>>524 NDAで説明してやるよ
公的認証で署名した誓約書何処かにうpしな
>>525 いくら自分が理解できないことだからって
そういう言い訳しちゃ駄目だよ
528 :
デフォルトの名無しさん :2013/11/20(水) 21:30:12.24
>>524 ちなみに、root-serversじゃなくてMSのサーバーを使う事にした
m.root-serversはド底辺が日本語で通報できるように、バックアップとして使用する事にしている
早く通報しろ ド底辺
>>527 最初から目的は企業秘密と断ってある
知りたいなら誓約書だせよ
同一ネットワークでそのプログラム使っているホストが沢山いたら、そこのデフォルトゲートウェイの負荷が増えるし、そういうアプリが沢山あったら、ホスト自身の負荷も増えるな。 アプリの目的にもよるが、マルウェア扱いされそうだ。
>>528 わからないならわからないってえ言えばいいのに
きちんとTTLの意味から教えてあげるよ?
くやしいのうwくやしいのうw
恥ずかしくて言えない企業秘密もあるさ
533 :
デフォルトの名無しさん :2013/11/20(水) 21:35:58.16
534 :
デフォルトの名無しさん :2013/11/20(水) 21:38:46.51
>>530 わかりませーん
ttl = 1のpingを10万人位がm.root-servers.netに向けて一斉に打ちまくると、
どこにどんな影響があるのか説明してくださーい
くやしいのうwくやしいのうw
>>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
542 :
デフォルトの名無しさん :2013/11/20(水) 22:27:21.19
>>542 あるなら早く出してね。
簡単でしょ?公式な文書から1文見つけるだけなのだから。
というより「決まりがある」と思っているそのこと自体が、 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.
自分で持ってきた英文をよく読んでごらん。 英語理解できないの?
547 :
デフォルトの名無しさん :2013/11/20(水) 22:39:56.86
せっかく貼ってやったんだから英文をよく読んでごらん。 英語理解できないの?
ド底辺 vs パシリ
549 :
デフォルトの名無しさん :2013/11/20(水) 22:42:48.64
このバカはどう読んで > そもそもルーターがTTLを1減らさなきゃいけない決まりはないし。 という理解に達したんだろう? 謎だ 謎すぎる 貼ってあげた英文翻訳してみてよ
翻訳してよ。英語理解できないんだからさw よろしくたのまー。
551 :
デフォルトの名無しさん :2013/11/20(水) 22:45:31.86
まさか、「1じゃなくて2引く可能性も3引く可能性もある」とか小学生みたいな事言い出すのかな?
やっぱり英文が理解できないようだね。 読めればすぐにわかるのに。
コイツちょっとからかっただけで勝手にファビョってage連投するなw 最高オモチャw
RFCはRequest For Commentであって規格書ではないから 従う決まりはないとか。
>>521 そういうのが流行ると、ttlを変えずにルートサーバーにping打ち続ける人が増える要因になる
>>554 状態がstandardになってるものは規格だよ
RFCを扱った人ならわかるはず 大文字「MUST」でなければ従わなくていい業界暗黙ルール ちなみに 「SHOULD」=少しは頑張ってみて 「MAY」=ちょっとは気にかけて だな
558 :
デフォルトの名無しさん :2013/11/20(水) 23:11:40.97
rfc 791にはMUSTは一回も出現しないが、インターネットは従わないても構わない業界暗黙ルールで動いているのか。 こりゃ、びっくりだ 爆笑
>>557 RFC791には「MUST」も「SHOULD」も書かれていない
という前提で言ってんだよな?
>>557 RFCの歴史から見たら、およそ後ろ半分にしか存在しない新しいルールだな
>>559 RFC791の頃にはまだお決まりのMUST/MUST NOT/SHOULD/MAYの話はなかったんだな
こりゃ失礼
562 :
デフォルトの名無しさん :2013/11/20(水) 23:26:30.53
これが「決まりはない」のオチかよ^_^
少なくとも1989年のrfc1122あたりでは"MUST"が出始めてるな。 およそあの時期からの流行だったと思う。
さて、もう寝るので明日朝までに回答よろしく。 答えにたどり着けなかったり、その他の逃げは敗北宣言とみなすので よろしく。 自分で貼った英文に答えはあるのに、なんでわからないかなぁ? だまされたと思って翻訳して貼ってみれば気づくかもよ? じゃあ頑張ってね。
566 :
デフォルトの名無しさん :2013/11/20(水) 23:37:40.01
どうやら「MUST」がオチだったようだ 知らないなら最初から黙ってりゃいいのに
>>566 ということにして、さっぱり理解できないこの話からは
とっとと逃げたいという敗北宣言ですか?w
568 :
デフォルトの名無しさん :2013/11/20(水) 23:49:53.32
逃げ^H^H寝たんじゃないのか 爆笑
>>545 にルーターなんて一言も出てこないじゃん。
これが答え。
571 :
デフォルトの名無しさん :2013/11/20(水) 23:52:20.78
バカが逃亡したところで巻き戻しておくか
>>397 みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
573 :
デフォルトの名無しさん :2013/11/20(水) 23:55:27.76
ダメとも書いてないからok
書いてないものは認められません 書いてないからokとか、どこの底辺PGだよ
書いてないことは好きにしてokだろ
そもそもunreachの一種だろ okって初めから書いてある
577 :
デフォルトの名無しさん :2013/11/21(木) 00:04:43.07
書いてある事しか認められないなら、仕様書にソースコード書かなきゃならんな。大爆笑
>>571 > その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが
どこぞの大学のNTPサーバーを使うのが日本で流行ったとき、
そのサーバーはDoS食らったような状態になったらしいな。
各々のクライアントとしては1パケット/1分より少なかったのにな。
m.root-servers.netにping打つのが同じように流行ったら
それは好ましいことだと思うか?
ttl = 1の意味がわからないなら聞いてくれていいんだぜ?
ttlはルーターで1減るとは限らない(どやぁ
ttl = 1の案が出てきたのって
>>397 より後じゃね?
47秒差で前
ほんとだ1個前か
まあ、47秒差じゃ
>>397 の時点ではttl=1なんて聞いてないだろうけどな
ルートサーバにping攻撃するようにしか見えんわ
そんなのを挙げ足とって馬鹿じゃね?
>>580 ヒヤリハットの法則でいくと
ttl=1でm.root-servers.netにpingを飛ばすやり方が一般化すると
その数十分の一はttl=1にし忘れる
本人がいまさら必死の自己弁護wワロスw
>>585 そんなことはこの作者のツールしか思いつかないから
100% ttl=1に決まってるだろうが
>>584 自分では正しく間違っていないすごいアイデアだと思っていたのに
通報とか言われて恥かかされて相当に悔しかったんだろうな
そしてキレて荒らしになったと
ttl=1じゃなかったとして、いったいどこに通報すんだよw これ自体が笑わせる煽りじゃんw
590 :
デフォルトの名無しさん :2013/11/21(木) 00:28:22.03
ド底辺が息吹き返してきたか?
不文律の説明してくれよ
>>397 みたいなド底辺って、いったいどういう集団に属しているんだろう?
その集団には、1パケット/1分(ttl = 1 大爆笑)を送ることが攻撃という不文律があるらしいんだが
> m.root-servers.netを襲うかもしれないし、
> 通報しておいたほうがいいんじゃね?
> こういう不文律が通じないアフォは徹底的に駆除するべき
>>589 ttl=1じゃなかったら普通にwideに通報して注意喚起するだろ
そんなアプリが普及でもしたら大参事だし
>>587 こういうどこでも良いから打ち続けられるpingの宛先として m.root-servers.net を候補にしてるのだが
それを選ぶのは良い選択かという話だろうが
一般論として、そこに向かって撃つのが最も妥当性が高いとでも言うつもりか?
>>592 個別の案件で勝てないから、一般論を持ち出してきたか
個別の案件として100% ttl=1が保証されているのだから、
一般論がどうかに関係なく、全く問題はない
>>592 ttl=1の時点で「打ち続けられるpingの宛先」じゃないんだよ
そこを理解できてないな
レコードが引ければ宛先はなんでもいいんだよ
m.root-servers.netのレコードを引くことすら、NSの負荷がとか
言いだすつもりかい?
で、ttl=1なのに固定にする理由は?
596 :
デフォルトの名無しさん :2013/11/21(木) 00:46:37.90
>>593 モデルガンを持って交番に行って警官に向かって打つふりをするようなものだよな
モデルガンだから問題ないと言ってるようだが
なんでわさわざそこを狙って打つことを肯定したがるんだ?
>>597 馬鹿はたとえ話をするな
全く意味がわからないぞ
>>533 増えると書いただけだが。
機器構成もホスト数もアプリ数も現状のトラフィック量もわからずに、何を見積もるの?
エスパー様にならわかるんだよねぇ?w
600 :
デフォルトの名無しさん :2013/11/21(木) 00:49:35.98
>>597 バカの例えは問題を発散させるだけだからやめろ
警官はモデルガンを向けられていることをわかるが、 m.root-servers.netはttl=1のpingの宛先にされていることを 知る由もない たとえ話にすらなっていないな
602 :
デフォルトの名無しさん :2013/11/21(木) 00:52:39.38
>>599 pingを最大1パケット/1分と条件つけてるので楽勝に見積もれる
全然問題ない
>>597 ttl=1なので、交番に1歩向かった自宅の玄関でおしまいです。
そこでいくらモデルガンを打っても、何の問題もないし、
警官にもばれません。
はい論破w
それで、ttl=1なのに固定にする理由は? 答えられないの?
>>603 なんでわざわざそこ狙うのかという話だろ
606 :
デフォルトの名無しさん :2013/11/21(木) 00:57:06.44
>>604 しつこいな
聞きたかったら誓約書うpしな
>>605 なんで狙っちゃいけないんですか?
交番に勤務する警官を絶対届かない自宅玄関から狙っちゃいけないという
不文律wでもあるんですか?
ttl=1でルートサーバーにping飛ばすのを流行らせたいテロ?
>>607 むしろなんでわざわざ大事なルートサーバーを狙う?
>>609 狙いたいから狙う。
狙っても一切無害だから狙う。
何か問題でも?
>>609 大事なサーバーだから、レコードも大事に扱われるでしょう。
なので大事なサーバーゆえに狙うのです。合理的な考えでしょ?
誰もが大事にするからターゲットにする。でも一切危害は加わらない。
わかりませんか?
>>611 たった一つの失敗でルートサーバーにパケットが飛ぶんだけど
そういうやり方を流行らせたい?
>>611 お前が綱渡りで遊ぶのは勝手だけど、失敗して他人に汚れが飛ぶような遊び方は止めろ
>>613 じゃあ、あなたは宛先をすべてルートサーバーにしてしまうかもしれない
失敗をしそうなので、インターネットをいますぐやめなさい。
ということと同義ですが?
たった1つの失敗といっても、言い出したらきりがないですね。
どうしてTTLだけ例外扱いして、その失敗だけが発現すると思うのですか?
むしろ、プログラムの構造上もっとも起きにくい失敗でしょう。
>>614 失敗しませんのでご心配なく。
あなたがブラウザでURLを間違えて、知らないサーバに負荷をかけてしまう
可能性のほうが圧倒的に高いですから。
>>615 勝手だろ。
実際にサーバーに負荷かけるわけじゃないんだし。
>>619 じゃあなんで質問したの?なんで固定にする必要があんの?
>>617 > 失敗しませんのでご心配なく。
この根拠のない自信は何て言う病気?
____ / \ /\ キリッ . / (ー) (ー)\ / ⌒(__人__)⌒ \ | |r┬-| |失敗しませんのでご心配なく \ `ー'´ / ノ \ /´ ヽ | l \ ヽ -一''''''"~~``'ー--、 -一'''''''ー-、. ヽ ____(⌒)(⌒)⌒) ) (⌒_(⌒)⌒)⌒))
>>619 は別人なので、間違えないように
>>620 前者の問には回答済み
後者は誓約書うpしたら教えてあげる、公的認証で署名すること
385 殿
誓約書
このたび情報開示を受けるにあたり、以下の事項を厳守することを、ここにお誓いいたします。
記
.開示された情報は如何なる理由においても第三者に開示しません。
. 有償無償に関わらず、開示された情報に基づくソフトウエアの開発は行ないません
. 前項、前々項に反する行為を行った場合は、私の責任において情報の回収をおこない、損害金として金1000万円を支払います
以上
平成 年 月 日
住所
氏名
ほんものの基地街の人ですか
最初から企業秘密といってる事をどーしても知りたいと言うので そんなに知りたいならNDAでと言ってるだけ
tcpdumpで観察してみると TTL1のパケットが出る前に UDPのパケットが大量に出入りしています ><
>>602 だから、それ見積もって何か意味あるのかよ。
>>624 >>626 385って何の385ですか?
ちゃんと会社名と所属と実名も出しなよ
もしかしてそんなこともわからなかったのかな?
>>628 > だから、それ見積もって何か意味あるのかよ
こういうド底辺な発言をしなくて済む
>>529 > 同一ネットワークでそのプログラム使っているホストが沢山いたら、
> そこのデフォルトゲートウェイの負荷が増えるし、そういうアプリが
> 沢山あったら、ホスト自身の負荷も増えるな。
>>629 誓約書は片務契約なので債務者の身元だけだけはっきりしてればいい
こんなことも知らないの?
債務者の身元しかわかってないと 仮に債務者が守秘義務違反を犯した場合に誰が損害賠償請求できるのかわかんないね
片務契約だろうが、甲乙は対象の組織や個人を特定できるように なっていないと契約として全く意味をなさない。 こんなことも知らないキチガイさん。
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秘密鍵をもつ者に支払います。
以上
平成 年 月 日
住所
氏名
>>635 あれあれ?
>誓約書は片務契約なので債務者の身元だけだけはっきりしてればいい
>こんなことも知らないの?
じゃなかったの?
人からちょっと言われたぐらいでもう覆しちゃったの?
こんなに自身たっぷりに言ってるのに
637 :
デフォルトの名無しさん :2013/11/21(木) 09:53:20.62
>>636 変わってない、やっぱ頭悪いなお前 ド底辺のバカさがよくあらわれている
そんな頭で「自身」たっぷりに煽っちゃったりして 爆笑
天然のキチガイが荒らすとダラダラと長いな
639 :
デフォルトの名無しさん :2013/11/21(木) 10:02:35.88
今日はどんなド底辺レスで笑わせてくれるんだろう 「自身」タップリなド底辺レス期待してるぞ
触ってる連中も同レベル
公開鍵だされてもホームレスかもしれないし そんな自分の身元も明かせない奴の文書に署名なんてできないなあ とっとと会社名と所属と実名を書きなよ
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とは違うのだよ。
>>644 それがどのようにアホなのかをお前の言葉で説明できないなら
ただアホアホ言うだけで終わるしか能のないお前もアホの同類
>>630 意味もなく見積もるド底辺かw
いるよね、形だけの意味ない文書書くやつ。
>>644 は天才なのできちんとアホなところを解説してくれる
649 :
デフォルトの名無しさん :2013/11/21(木) 20:46:07.34
>>646 ,
>>648 ここまで読んで理解できないアホには永久に理解できない
>>647 プログラムを作るときは常にリソースの負荷を考えながら作るもの
ド底辺は救いようがないな
>>649 要求仕様の環境を読めよ。
負荷を抑えるのにはコストがかかるから、適切な負荷はあっていいんだよ。
できるだけ負荷を抑えるとか、できるだけ速くとか、意味のない仕様書しか書いたことないのか?
>>649 誰が何を読んでどう理解するかは全然関係ない話。
お前は説明能力がないんだなと思われてる状況で
お前自身がその行動でそれを証明してるわけだ。
652 :
デフォルトの名無しさん :2013/11/21(木) 21:26:43.57
>>649 ド底辺の典型だな
三菱インフォメーションシステムズもそうやって開発してたんだろうな w
>>651 無脳症に説明する能力は持っていない お前以外はわかってるから問題ない
この業界、説明能力がないと大損だよな
654 :
デフォルトの名無しさん :2013/11/21(木) 23:44:55.93
俺もわからないんだが。
皆がなんとなくわかっているのは 恐らく目的に対してPingで解決する必要はないだろうなって事ぐらい
みんなでpingすればDOS
そんなに煽らんでも誓約書出せば教えてあげるよ 爆笑
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とは違うのだよ。
質問終わったならとっとと消えろカス
イヤだね ここが俺が唯一輝ける場だ
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とは違うのだよ。
もしかして通報されて怒られた経験でもあるの?w
通報はされてないけど 社内のネット缶から電話掛かって来て 怒られたことはあるな 「それがどうかしましたか?」 って言ってやったら黙ったけど
かわいそう・・ 周りの人が
※上司に報告されてマイナス査定されたことは黙っておきます
原理原則論は現実の前では役に立たない
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とは違うのだよ。
iPhoneとかでWiFiのアクセスポイントに繋ぐと自動で認証画面のWebページが開くやつってどういう仕組みでやってるのかな?
676 :
675 :2013/11/25(月) 14:08:22.81
proxy設定しといて、そのproxyが全部やるんじゃなかろうか
678 :
675 :2013/11/25(月) 14:28:05.44
>>677 それってアクセスポイントに接続したあと、ウェブブラウザを開いて80番とかで通信しようとしたときにトラップしてログインページへ誘導するするやり方だよね…
iOSでアクセスポイントに繋いだだけでWebブラウザを開いてないのに自動で
>>676 みたいな認証画面がでるんだけど、この仕組みがわからんぬ。
Windows でも 勝手に IE が開くときと 反応が全く無いときがあるな ルーターとの相性っぽいが
682 :
675 :2013/11/25(月) 14:56:57.02
>>680 >>681 1. iOSでアクセスポイントに繋ぐ
2. SafariをアクティブにしていないのにWebページの認証画面が勝手に出る
という「勝手に出る」仕組みが知りたいわけなんだが…
>>680 >>681 だと、DHCPサーバからIPアドレスをリースされた後に、HTTP/HTTPSな通信がどのような方法で開始されたのか説明が無いので「勝手に出る」わからんぬ。自分でSafariを立ち上げて適当なWebサイトにアクセスする場合は分かる。
勝手に出るかな? プロファイル入れてんじゃねーの?
馬鹿には無理
685 :
675 :2013/11/25(月) 15:29:11.31
プロファイルを入れると開くようになるってこと? 例えばソフトバンクがプロファイルを仕込んでおくとソフトバンクが用意したFON FREE INTERNETにアクセスした時に開くようにできたりするってこと? 技術名称が分かればあとは自分でなんとかできるんだが
キャプティブポータル認証 ?
689 :
675 :2013/11/25(月) 17:50:17.28
これが彼の逮捕のきっかけになるとは その時は誰も知るよしもなかった
692 :
675 :2013/11/25(月) 18:00:51.73
いやいみわからんがなw
693 :
675 :2013/11/25(月) 18:01:22.94
ハニポとかしないからw
695 :
デフォルトの名無しさん :2013/11/28(木) 20:28:14.04
誰かを襲う可能性があるからインターポールに通報すべき こういうアフォは駆除しなきゃいけない
本人にそのつもりは無くても 捕まるときは捕まるからなぁ
697 :
デフォルトの名無しさん :2013/12/09(月) 11:16:00.76
194.85.61.0/24 が糞な件
>>697 class C まるごと乗っ取られてるなω
rawsocketについて教えて下さい。 Windows8.1 VC12でプロミスキャスモードを利用してデスクトップアプリ(chrome)の通信をキャプチャしようとしています。 送信パケットは取れるようになったのですが、受信パケットが取得できません。 該当しそうな単語でググってはみたのですが手詰まりでして…。 見つけたサンプルプログラムをビルドしてみても同様でした。 Wiresharkではう見れているので最終的にはWinPCap使えばなんとかなるとは思うのですが、何か思い当たることがあれば御教授頂けますでしょうか。
>>699 Windowsファイアウォール無効にしてみた?
>>700 それでした。
通信許可する一覧に追加したら受信パケットも取れるようになりました。
些細なことでお手間とらせました。ありがとう。
誘導されてこちらに来ました 質問内容は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" というエラーが出ます。 調べてもなかなかそれらしい対応策がみあたりません。 なにかアドバイスがあれば宜しくお願いします。
>>703 > 1.ファイルディスクリプタをselectに設定する際の値
man selectしろアホ
> 2.boost がコンパイルエラー
スレ違いじゃボケ
705 :
703 :2014/01/15(水) 15:14:44.10
>>704 ?
だから、man select いわくSOCKET + 1 だけど、少しだけ大きいことが大きな問題になるの?
って質問なんだけど?
2.に関して誘導してもらえると助かります。
>>703 「ソケット select nfds」でググるとトップに「select(2)の第一引数にディスクリプタの最大値を渡すのは間違い?」という
ページがヒットするんだが、当然ここは読んだんだろうな?
>>705 > だから、man select いわくSOCKET + 1 だけど、少しだけ大きいことが大きな問題になるの?
> って質問なんだけど?
しるかボケ
心配ならソース読め
> 2.に関して誘導してもらえると助かります。
この板のスレ一覧をboostで検索することも思いつかないのか
>>706 そのページのリンク先のMicrosoftのページには
> nfds [in]
> Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
って書かれてるね。
manでmax(all fds)+1を渡せって書かれてるのに、なんでそれに従いたくないの?
>>707 知らないならノイズが増えるだけだから回答を差し控えようよ
711 :
703 :2014/01/15(水) 16:13:14.75
>>706 おおおおお
私はあなたを愛してる
ちょびっと感動。
712 :
703 :2014/01/15(水) 16:18:14.90
>>708 うむむ
この悩み多き子羊に悩みをふやすとは。
実は、Windowsベースで開発するか、Linuxベースで開発するか、JavaなのかC++なのか
悩み多き状態でありまするです。
bdb を別の目的で使っているのでなんとなく感動ですが、
変にブロッキングされないのであれば、どーーーんと大きな値をってやつですかね?
713 :
703 :2014/01/15(水) 16:21:29.31
>>709 非常に単純なコーディングの問題
大して適当な大きな値で問題なさそげなのに、なぜnfds + 1 なんだろうか?、と
#死んでもタイムアウトは使わんポリシーは維持しております四
この場合、fdsの値を計算で出すにしろ、もうっちっと適当な値でも問題ないのでは?と
そうするとコードが非常にシンプルになりまする
そんな手抜きコードでシンプルとかお前終わってるよ
715 :
703 :2014/01/15(水) 16:47:38.37
>>714 終わってるかもねぇ
ただ、最大値+1で無くとも動くのになぜ、最大値+1なのかに疑問が生じたから、とだけ言っておこう
716 :
703 :2014/01/15(水) 16:49:20.70
>>713 そんなところを悩みどころにしてるようじゃ、まともなプログラムなんて到底書けないから
仕様通りに書いても大して難しいコードにならないのに
>>715 > ただ、最大値+1で無くとも動くのになぜ、最大値+1なのかに疑問が生じたから、とだけ言っておこう
だから知りたきゃコード読めば正解がわかるだろボケ
久振りにきたら沸いてるね
いつ来ても涌いてる
送信先のNICを指定したいんだけど どうしたらいいかな
Linux なら SO_BINDTODEVICE 他の環境は知らん
>>723 ありがとう! これは素晴らしい
オレのインターフェースにSO_BINDTODEVICEしてもいいよ
ていうか、いつのまにこんなオプション出来てたんだろ・・・
ソケットってどんどんオプション増えてくな
socatコマンドで、接続元IPアドレスを知りたいんだけど 環境変数かなんかで見れたりする?
>>722 奴らは街角で拉致られてタコ部屋に押し込められて強制労働させられてるのか?
自ら希望して派遣会社に登録したんじゃないのか?
まずそこをハッキリして貰いたいんだが。
NICってそんなに恐ろしいのか
確かにでかいルーターに押し込められてる NIC はタコ部屋って感じがするな (w
windoswにおけるネットワーク通信はすべて winsockライブラリを通して行われているの?
win dos (w
widsdomはない
netbios.dll は何もしないのか
winsockの勉強を始めてconnect使ってみたんだが適当なアドレス(111.111.111.111とか0.0.0.0)とか入れてみても全くSOCKET_ERRORを吐いてくれない これってこういうもんなんですかね?
UDP
735 :
デフォルトの名無しさん :2014/04/15(火) 11:58:23.72 ID:FRZaT020
openssl
先に進めてみればわかる
特定のマシンにARPパケット投げて、 ARPテーブルのMACを書き換えているのですが、 無線LANの場合、期待通りになりません。 原因わかりますでしょうか? Windowsで最新WinPcapライブラリ使って ARPパケットを投げています。 両マシンとも無線LANで同じネットワークです。 アクセスポイントの問題かな。
738 :
デフォルトの名無しさん :2014/05/17(土) 23:13:54.36 ID:G8Lb2FJE
MAC偽装しているなら、無線区間のMAC偽装はWinPCAPではできない
>>738 なるほど、そういうことでしたか、納得。
WinPcapライブラリの使い方の良い情報源はないでしょうか? できればC#から使いたい
741 :
デフォルトの名無しさん :2014/05/21(水) 21:08:37.78 ID:v/u6M390
WinPcapNet
ありがとう
ここにいる人たちには初歩的なことかもしれませんが、教えてください Linuxでソケットを使ったプログラムを作っているのですが、少し大きめのデータを何個かsend,recvした後に サーバ、クライアントでcloseするとconnection reset by peerが時々出るようになりました。 closeするタイミングによってまだ残っている処理(send,recv)が取り残されているように思うのです。 サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか? よろしくお願いします
>>743 通常はcloseしても送信しきる先に切られることは無いので
別のことが原因と思います
>>743 >サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか?
クライアントとサーバ上のアプリケーション間通信について、
以下のケースに応じて通信の終了に関する規約(プロトコル)を決める
(1) データ送信が必ず一方向のケース(例:パイプ)
送信側は任意にcloseできるが、受信側ではソケットからの
終了通知(データ長=0)を待ってからcloseしなければならない
(2) 要求/応答のペアからなるトランザクションが常に同一側で発生するケース(例:HTTP/FTP/SMTP)
要求メッセージ送信側は任意にcloseできるが、応答メッセージ送信側では
ソケットからの終了通知(データ長=0)を待ってからcloseしなければならない
(3) データ送信要求が任意の時点かつ双方の側で発生するケース
制御メッセージとして通信終了要求(例:"QUIT")と通信終了応答(例:"OK")を定義し、
正常に通信を終了させたい時は終了要求メッセージを送信し応答を待つ
要求を受信した終了受け入れ側では応答メッセージを送信して即座にソケットをcloseする
終了要求側では応答メッセージ受信を確認してからソケットをcloseする
(3)のケースは複雑な手順を踏まなければならないのだから、連動テストで問題が発生してから
解決策を悩むのではなく、上流の設計工程でアプリケーション間通信プロトコルの全体を
ステートマシンとして形式的に定義し、正当性を検証しておくことが望ましい
>>746 にあるとおり、アプリケーションレイヤのプロトコルを決めてないところに問題があると思う
このメッセージを送信したらcloseする、このメッセージを受信したらcloseする、とか
mibをダンプするコマンド(nstatとか)でTcpExtTCPAbortOnCloseがインクリメントされてたら、
>>743 の推測通り、アプリケーションがメッセージを吸い上げる前にcloseが発行されてると思う
無線で電波が途切れた場合とかどうテストしたらいいん?
>>748 ・単体テストであれば、スタブ側で電波途切れのエラーを返す
・有線で組み通信中にケーブルを引き抜き擬似的に現象を起こす
・金属ケースや地下室などの電波を遮蔽できる環境を用意する
頭を使えば、様々なアイデアがでると思うよ
>>748 どのレベルのプログラムの話なんだ?
ドライバ?ネットワークスタック?アプリケーション?
>>748 ノートPCを持って電波が途切れる所まで離れてみる
青歯で実際にやったことあるぞww
相手の電源切ればいいじゃん
753 :
743 :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となる
という感じでした。
何らかの例外ってのがあやふやなのと、元々あまり発生しないエラーだったので本当に解消できたのか
不安なところはあります。お付き合い頂き有難う御座いました。
ところで相手がデータ受けとる前にcloseしたら 相手がデータ受けとる前にセッション切られてしまうという誤解、 これ広まったのはいつ頃からなんだろうか。 とても気になるな
755 :
デフォルトの名無しさん :2014/06/13(金) 14:25:16.96 ID:3lbuf2Ok
ハーフクローズでデータ受けるとRST返してしまうから 相手側はデータ受け取る前にセッション切られるんだよ FINに対してFIN/ACKを返したときはrecvでデータ受けきることができるけど RST受けたときはその時点で終わりという実装が多い 誤解というか最悪ケースってやつで、セッションは切られるかもしれない 前提で設計しないと、ひどい目にあうっていう話だね
ちょっとそれだけだと詳細がわからないな その広まってる誤解っての寡聞にして知らないんで、 具体的におしえてくれないかな? とりあえずTCP?
>>754 > ところで相手がデータ受けとる前にcloseしたら
この行のclose操作は送信側で起きるんだよね?
(受信側はrecvで待ち続けているのだから....)
もしそうだとしたら、
> 相手がデータ受けとる前にセッション切られてしまうという誤解、
のような話は聞いたことがない
というか、TCPコネクションが双方向のパイプ(バイト・ストリーム)として
モデル化されることを理解していれば、誤解など起きるはずもない
実際、
>>746 のケース(1)は、送信側が任意のタイミングでclose操作が
起きることを想定しているけど、これはUNIXのパイプと同じだから、
一部でもデータが喪失することを発想してしまうのは信じ難いな....
>>758 世の中にはその辺あんま理解してない子が結構いるのよ
読む気がしないが分かっていなさそうなのは分かる
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」 どちらですか?
TCPですすみません
763 :
デフォルトの名無しさん :2014/06/14(土) 22:01:22.78 ID:DYTXSKWp
TCPですすまないならUDPでやれば
順序は保証されてるでしょ 分割の切れ目がどこになるか保証されないだけで
>>764 つまり分割されたとしてもデータAを受信し終わってからデータBを受信開始なんですね
ありがとうございました
あらやだ
バーカ
>>761 TCPスタックから見ればパケットが届く順はBになりえるけど、
アプリケーションの作り方として、最初にacceptしたコネクションから
全データをreadするまで別のコネクションはacceptしないとか、
acceptはしても最初のコネクションの分割メッセージを全部受信し切るまで
別コネクションのデータはreadしないとかにすればAになるかな
アプリケーション側での受信順のためにわざわざそんな変な造りにするのは本末転倒な気がする。
A:煙草吸ってもよろしいですか? B:どうぞ。ところで一日に何本くらいお吸いに? A:ふた箱くらいですね。 B:喫煙年数はどれくらいですか? A:30年くらいですね。 B:なるほど。あそこにベンツが停まってますね。 A:停まってますね。 B:もしあなたが煙草を吸わなければ、 C:ちくわ大明神 B:あれくらい買えたんですよ。 A:あれは私のベンツですけど。 B:誰だ今の
最近は馬鹿が出没してるらしいですわよ、気をつけなきゃ
そうわよ(便乗)
>>761 正解は「C, 挙動は非決定的であり事前に予測できない」になる
つまり A かもしれないし B かもしれないし、その他の挙動が起きるかもしれない
たとえば「0A1B2C3....」もあれば、最悪のケースだと「ABCDEFG12345...」もありえる
あるアプリケーションがsend操作を発行して全データを送信し終えたとしても、
それはあくまでソケットAPIへの送信要求が完了しただけであって、
そのデータを相手側アプリケーションが「いつ」受信するかを事前には予測できない
一般にデータ受信側アプリケーションでは、バッファ上でメッセージを組み立てる
つまりメッセージの終端に到達するまでselect+recv操作を反復してバッファに保存し、
終端に到達したタイミングでバッファからメッセージを取り出して受信手続きを実行する
サーバでは、この一連の手順を各クライアントごと並行に処理することになる
ここで後だし
A:かもしれないし B:かもしれないし C:ちくわ大明神かもしれないということですよ
>>776 正解はBだが、Cのちくわ大明神は現れない場合もあることを想定する必要がある。
TCPの場合、ちくわ大明神が現れなくてもリトライしてはいけない。
なぜならばTCPの中の人がちくわ大明神を呼び出してるから。
778 :
デフォルトの名無しさん :2014/06/16(月) 01:27:25.37 ID:Hr3juoVp
中だし
UDPでパケットの到着順序は保証されないけど 実際に順序ひっくり返してみたいんだけど どういうふうに試験環境用意すればいいかな。
>>779 再現困難だから、実際にひっくりかえして送信(しても耐えられるかどうか)をするのがいいのでは?
dummynetみたいなやつでエミュレートする
accept 後の それぞれのソケット(A, B) からみれば ソケットA 「0123456789」 ←これが細切れになるやもしれない ソケットB 「ABCDEFG」 ←これが細切れになるやもしれない こういうことでないの?
パケットの分割自体はサーバー側で織り込み済みだ いつまで引っ張る
socketでサーバを作成し、Teraterm(クライアント)から接続したのですが、 Telnetと同じように1文字ずつ、入力のたびにパケット送信したいのが、 Enter押したときにしかパケットが送信されません。 Teratermで 1文字入力する毎にパケット送信するためにはどうしたらよいでしょうか。
適切な板とスレッドを選択して質問する マニュアルを読む ソースを読む 好きなのをどーぞ
>>782 ソケットAとBから同時にサーバーに送信した場合の話をしてるんだが
ソケットAを受信し終わる前にソケットBの断片が届く可能性はある
>>786 そんな話をしていたのかよ
そんな順序誰も保証してないよ
とんでもねー後出し
>>786 ソケット違うんだからデータが混ざったりしないし
順番なんてどうでも良いんじゃないのかい?
ど素人なのだろ、ほっとけ
>>793 WSAAsyncSelect()の第一引数を無視してるから混ざると困るって事だろねw
>>793 ファイルを2つオープンして、それらからデータをリードしている
ここで、2つのファイルのデータが混ざってしまう事を
心配しているのが
>>786 ,791なんだよなあ
まあ、彼らのようなプログラミングの初心者にとって
複数ファイル処理は難しい課題なのかもしれないけど、
もしも
>>761 がそのレベルの課題を質問したいのなら
「ネットワークプログラミング」というスレの主旨から外れるから、
別の初心者スレで遊んでほしい
796 :
795 :2014/06/17(火) 20:05:55.36 ID:Kpke8le7
アンカをミスっていたので、訂正
X: 心配しているのが
>>786 ,791なんだよなあ
O: 心配しているのが
>>786 ,793なんだよなあ
>>795 WSAAsyncSelect()を使った場合、ソケット毎に別の格納用のデータ構造が必要だって
のはネットワークプログラミングの範疇じゃないのかい?
WSAAsyncSelect()じゃなくてソケット毎に別のスレッドにすればそんな問題は発生
しなくなるがスレッドだとまた別の罠がある。
スレッドの罠はネットワークプログラミングの趣旨から外れるなw
データは混ざらないけど、時間軸で追っていくと、到着に規則性がないのが大前提 (だから、うまくやれ
時間→
A "01234" "567" "89"
B "ABC" "DEFG"
Aが先に構築し始めてるけど
Aのメッセージ(123456789)が 完成する前に
Bのメッセージ(ABCDEFG) が完成することだってある
だから A用バッファ B用バッファ (
>>797 でいうソケット毎に別の格納用のデータ構造) を用意し、
ハンドラで、A向けかB向けかを判断いたうえで、しかるべきデータ構造に詰んであげる必要がある
>>795 元はクライアントA→サーバー→他クライアントへって処理だから
FD_READで同じ処理させればいいだけなんだし
ソケット分岐する必要があればソケット別に処理させて
ソケット分岐する必要がなければそこらへん意識せず処理するだけで終わるだろ
ファイルとか例えが下手すぎる
>>797 ファイル処理では、ファイル毎にファイル記述子を格納する
変数が必要なのは、常識ではないのか?
そんな常識すら知らない初心者に手取り足取り教えるのが
このスレの主旨だとは、少なくとも自分は思わない
>>799 デバイスの抽象化という概念を知らない素人が口出ししても
恥をさらすだけ
>>801 何が気に障ったのかわからんが論点ずらさんでも
玄人は初心者とか素人って言葉使わないんだけどな
自惚れてる人が良く使う
>>761 に対しては
Aが受信終わる前にBのデータが割り込む可能性があるから
ソケット毎にデータを処理するべきで終わってた話だろ
>>802 その終わっていた話に対して、わざわざボケをかましたのが
>>793 だろ
というか、ID:LnB6vTqT の理解レベルが、他と比べて低すぎる
無知は決して恥ではないけれど、無知であると自覚できないのは無能だ
>>800 ファイルストリームではSelect()のように同じ所に返って来たりしないからな。
世の中には、ファイルストリームがストリームソケットになっただけで同じものなのに
わからなくなるヤツが居るのさ。
ま、言いたいことは分かるがそんなに目くじら立てるな。
Winsockを使うのなら
>>1 の2つ目のリンク先くらい見ておかないとね。
古いんで今では正しくない部分もあるがかなり参考になると思う。
>>803 話の流れ見てから言え
発端の前提をぶっ壊して話されてもな
エスパーでもないのに俺のレスのどこで理解レベルがわかるんだよ
>>761 が危惧してた事を言ったまでだぞ
とりあえず誰かを見下したいなら他行け
>>807 見下すも何も、2つのファイルや2つのソケットを扱う処理で、
それらのデータが混ざってしまうことを危惧しているのは
ID:LnB6vTqT、ただ一人だけ
他の連中はクライアントを識別するはソケット記述子で判断できるという
常識を前提にして議論しているのに、ID:LnB6vTqTは知らなかったんだろ?
だから
>>793 みたいにトンチンカンなボケをかます
誰でも成長の過程で間違いをおかすことはあるんだから、
それを素直に認めたほうが前向きな生き方だと思うよ
>>808 サーバー側が受信するデータの順番で言うと
データAとBが「01234」「ABC」「56789」「DEFG」と交互にくる可能性があるか聞いてるんだろ
つまり混ざるかどうか
>>808 が言う所の混ざるとはrecv1回のデータの中にデータAとデータBが同時に存在するかどうか しないわな
>>761 が危惧してるのは同じデータ領域を使用して末尾に受信したデータを連結した場合混ざるかどうか ソケットで分けたら解決
ここの認識がずれてるぞ
で
>>761 がそういう危惧してるから
>>761 は聞いてるんだろって話
話の流れと質問者の意図を汲み取れよ
汲み取りやてんの、下水が普及してないのか
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の際にソケット識別子を(渡ってきたものを使わずに)自前解釈で決め撃ちしてるのか?
>>811 どこがや
>>812 ソケット毎に分けるという発想が
>>761 の時点で無いから
ソケットAもBも同じFD_READ・recvでやる前提と思うぞ
だからソケットAの受信が終わってからソケットBの受信開始なら現状維持でいいけど
recv1回目はソケットAのデータ、recv2回目はソケットBのデータってなる可能性があるなら変更しないといけないから聞いたんだろ
>>813 複数コネクション張っておいてソケット識別子を使わないという発想はなんなんだ?
だったら、1コネクションしか受付け無いようにしとけば一挙に解決!
>>814 受け取ったソケット識別子を使ってたとしても
受信順がソケットAが終わってからソケットBなら開始終了だけ知ってデータ格納先は1つでもいいけど
受信順がソケットAが終わる前にソケットBも来るならデータ格納先をソケット毎に用意しないといけないから
それで聞いてたんだろ
>>813 >ソケット毎に分けるという発想が
>>761 の時点で無いから
なぜ
>>761 にはソケット毎に分けるという発想が無いと断定できるのか?
もしかすると ID: LnB6vTqT はエスパーなのかもしれない(
>>807 )
あるいは「
>>761 == ID: LnB6vTqT」だったりしてw
なんとなくゲスパー FD_READ 受けた後の記述は recv(渡ってきたsockを受けた変数, バッファ) だから表面上は同じものに見えてる 渡ってきたsockを受けた変数の 値が 適宜切り替わっているということに思い至っていないので、 値(識別子)による分離にたどり着かないのか
>>816 また論点ずらしか?
ソケット毎に分けるという発想があったのなら
そもそもあんな質問出てこないだろ
素人と汲み取り
>>815 ソケット毎の格納領域を用意するのがそんなに手間なのかw
ある程度力がつくと周りを見下し始める ある程度極まってくると印象を気にし出す 天狗のまま戻ってこれない奴も多いけど
0123456789が、01234, 56789に分割される程、フレームサイズの小さいL2プロトコルって何?
例えに突っ込むアホ?
最長データサイズの見積もり無しに、分割の可能性を心配する無能さをからかいたかっただけだよ。
>>824 空気抵抗をゼロとする、って問題文を読んで
「そんなことあるわけねーよプゲラ」
って言っちゃうタイプだよね
>>825 バカはたとえ話するな。空気抵抗必死で計算しようとしてるのが元質問者。
>>826 の例えの方がわからんわ
そもそもデータ受信時に割り込みがあるかどうかなんだから
最長データサイズの見積もりの必要なんて無いだろ
L2のフレームサイズより小さければ分割は発生しないの
ソケット識別子を知らなかっただけなのに なぜここまで続くのか
830 :
デフォルトの名無しさん :2014/06/18(水) 14:44:51.76 ID:Djkr0MFk
>>828 MSSもWindow SizeもReveive Bufferも全否定かよ
>>829 そうじゃなくね
Aなら受信データ格納先を1つで出来るが
Bなら受信データ格納先を複数用意する必要があるから聞いてたんだろ
>>830 覚えたばかりの言葉を使いたいのはわかるけど、
意味を理解してから使いましょうね、ぼくちゃん
IDが導入されて本当に良かった
>>829 Select系のAPIを使って居るのにソケット識別子を知らないのは痛過ぎるから
>>824 TCP/IPの背景にあるインターネットワーキングとは、
不均質なサブネットワークが相互接続される世界である
ここで不均質(heterogeneous)とは、L1プロトコル、
転送速度、フレーム長等が混在している様相を指す
従って一般的な原則として、TCP/IPアプリケーションの
設計において特定のL2/L1プロトコルを前提にすべきではない
いいかえると、最長データサイズを事前に見積もりできるとする
発想のほうが初歩的な誤りであって、(
>>761 のように)任意のバイト境界で
データの分割や組み立てが起こりうることを想定して設計する姿勢が正しい
つまり、この件に関して言えば、
無能は
>>761 (ID: LnB6vTqT)ではなく、
>>822 (ID:ID: 7tSp0AS9)のほうだ
>>755 や
>>822 は、素人がネットワークを勉強して知識を得たけれど、
それをプログラミングへ生半可に適用させて火傷を負う典型的なケース
水平軸における対向するレイヤ間のプロトコルと
垂直軸における上位レイヤへ提供するサービス(インターフェイス)という
交差する2つの概念をごっちゃにして理解しているように思われる
IPoAC か
タコがエスパー失敗
>>837 あらゆる可能性を想定出来ない奴がプログラミングとか趣味でやるだけにしとけ
あらゆる可能性を想定してプログラミングを書くやつはタコ 仕様も知らん奴は趣味でプログラムするだけにしとけ
>>835 struct pkt {
int32_t size;
char data[*];
};
こんなパケットの先頭のsizeを読むときも
if (read(s, &size, sizeof(size)) != sizeof(size))
error();
としないのか、大変だな。頑張ってくれ。
>>845 > 発現しにくいバグ生むだろそれ
意味不明
わからないならそのままでもいいんじゃね
>>845 仕様です。
って一言が、これほど上手く使えるとは。
>>842 >あらゆる可能性を想定出来ない
「想定外です」霧
>>847 4バイト来ることを想定しちゃいかんって事かな?
あと、バイトオーダーも無視してるし
853 :
835 :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が自分のカキコになる
タコが釣れたぞ
>>853 今時は、全銀手順の手組なんてしないしw
ライブラリー使いましょ。
>>854 ネットワークスレなんだからオクテット足が釣れたと言いましょ
>>853 銀行で徹夜したことについて謝罪と賠償を請求する
良く読め、銀行間取引って書いてあるだろう? 日本は銀行間取引はRTGSで日銀経由でしている事を 知らない部外者だよ
タコはみずから足を出す 片山まさゆき
今読んでもノー爆は面白いよな
860 :
デフォルトの名無しさん :2014/06/20(金) 06:36:54.81 ID:JSi28Lkj
>>853 > さて、この障害連絡に対して
>>844 はどう返答する?
error();
の中で処理する。
>>861 #318ではなく#938の可能性微レ存だが、銀行間の数十万件の取引レコードを
処理するプログラムを書く御仁がこんな単純な間違いをしたと、決めつける
のは良くない。本人の釈明を待つことにする。
863 :
835 :2014/06/20(金) 09:20:27.39 ID:fiYVjyLm
>>860 指摘ありがとう、レス#の間違いに気が付けなかった....
X: この過去スレの#318が自分のカキコになる
O: この過去スレの#938が自分のカキコになる
具体的な疑似コードは、過去レス(
>>853 )の #947 と #950-952
> tlv = reader.get()
プログラムがここで寝ている時に通信障害の連絡やってきた。
さて、
>>853 はどう対処する?
銀行間の数十万件の取引レコードの転送の場合は当然
switch (tlv.type) {
default:
error();
brreak;
}
なんて事はしないんだよな。 w
非同期(950-951)の場合 > 質問の意図に沿って「非同期I/Oを前提(だよね?)」とした場合、最も外側のTLV構造の処理は、 > ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。 こっちの場合も while (buf.size() > 0) buf.size() == 0で抜けてしまうんだが、 while (buf.size() > 0) { } if (state != STATE_COMPLETE) error(); なんて事はしないんだよな。銀行間の数十万件の取引レコードの転送の場合は w
866 :
835 :2014/06/20(金) 11:57:20.19 ID:fiYVjyLm
>>864 「寝ている」とはプロセスがブロック(or スレッド)された状態を意味するのかな?
もしそうなら、過去スレ#950の冒頭で述べているように:
・マルチスレッド構成でTCPコネクション単位に
スレッド処理する設計ならば、ブロックには何の問題も無い
新たに受信データ断片が到着すればスレッドのブロックが解除され、
次のtype別処理を再開できるのだから
・シングルスレッド構成でイベント駆動処理を前提に設計しているのならば、
過去スレ#947の疑似コードは不適切だから
代わりに#950の疑似コードを使えばいい
>>865 バッファが空である(buf.size() == 0)ならば
現時点で到着していた受信データ断片の処理は終わったのだから、
ステートマシンの状態を保持したまま
すみやかにコールバック関数をリターンし、
次の受信イベント発生を待ちうけるべき
こんなのはイベント駆動プログラミングの基本だけど、
>>865 はどんなエラー処理を期待しているのかな?
通信障害が発生してもreadは0を返さないのかな? 銀行間の数十万件の取引レコードの転送の場合は w
通信障害が起きたのならヘッダ部だろうとボディ部だろうと 途中でエラーになるんだから 安全を取って、その電文はエラーログに落として破棄、 ランプ光らせつつ再送に期待じゃない?
そのためにタイムアウトがある
870 :
デフォルトの名無しさん :2014/06/20(金) 13:06:50.29 ID:5fUr2YwO
何を言い争ってるのか知らんけど、 selectとnon blocking I/Oを使うんだぞ それから実装はどうであれSOCK_STREAMのsocketからreadしたとき 何バイト読めるかは保証されていないぞ
871 :
835 :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操作がエラーリターンするよう変更してもいいけど、可読性は落ちる)
とタコが申しております
銀行系は言われてないことをやるとクビになるよ
874 :
835 :2014/06/20(金) 13:51:26.94 ID:fiYVjyLm
>>870 そのとおりで、TCP通信がバイト・ストリームであることを理解していれば、
保証されないことは当たり前なんだけど、それを保証するコード設計なんて
面倒くさくてやってられない、というのが
>>844 君の主張
>>844 のコードだと、保証処理を放棄して、通信エラーとして扱うつもりでいる
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、 > その部分で適切に通信障害発生時のエラー対応処理を実装する 銀行間の数十万件の取引レコードの転送の場合は、通信障害でTCPの切断が起こっ た事と通信終了でreadが0を返した事を判別できるのか? それはビックリだよ。w
876 :
835 :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
878 :
835 :2014/06/20(金) 16:00:42.03 ID:fiYVjyLm
>>877 > 後出し仕様 wwww
もともと過去レスの疑似コードでは、
readシステムコールを発行する詳細コードを抽象化し、
TLVリーダやバッファといった用語を書いている
そして、その実装は各自で考えてもらえばいいと思っていたけど、
ID:JSi28Lkj君が「僕には実装方法が分かりません」と言い出したから
丁寧に教えてあげているだけだよ
> 下位レイヤーが上位レイヤーの状態を知ってるんですかあ?
知らないから、下位の受信メッセージ組立て処理では
「単純に上位へコネクション切断を通知」して
上位のトランザクション処理に判別を委ねると、
>>876 で述べている
もう少し冷静になって文章を読んだほうがいいと思うよ
こちらでは技術関連は指導できても、日本語の読解能力までは面倒みれないから
大型はハードウェアがなんでもやってくれる、らしい(適当)
880 :
デフォルトの名無しさん :2014/06/20(金) 17:15:41.46 ID:fmtXRHPg
>通信障害でTCPの切断が起こった事と通信終了でreadが0を返した事を判別できるのか 通信障害は-1が返ってくるし
>>874 > TCP通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
882 :
デフォルトの名無しさん :2014/06/20(金) 17:40:23.44 ID:JSi28Lkj
>>878 > 知らないから、下位の受信メッセージ組立て処理では
>>876 には
>・ここで扱っている受信メッセージ組立て処理の場合、
> メッセージ組み立て中の状態でreadが0を返せば、
> それは通信障害によるコネクション切断と判断する
下位レイヤーが、上位レイヤーがメッセージ組み立て中の状態である事を知ってるっ
て書いてありますが。www
バカからかうのも面倒くさくなってきた。 メッセージ境界が保存されない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; }
884 :
835 :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を使う時点で素人 とか言ってみる
>>880 > 通信障害は-1が返ってくるし
はい、ダウト。 www
TCPの切断では-1は返ってこない。このバカこの程度の知識で偉そうにしてて大爆笑だわ。
ID:JSi28Lkj が哀れすぎ。見ててつらい
891 :
デフォルトの名無しさん :2014/06/20(金) 20:22:24.13 ID:JSi28Lkj
>>887 最後と言ってたのにやっぱり出てきた。バカ見苦しいぞ。www
> 無限に
> 無限に
> 無限に
> 無限に
> 無限に
ID:fiYVjyLm = ID:fmtXRHPg 説なの? わっかんねー
>>887 ちゃんとしたヤツならソケットオプションでタイムアウトを設定するでしょ。
>>888 blocking I/Oに複雑怪奇で挙動不審なスレッド実装
何も分かっていない素人ほど複雑な実装をする
ID:fで始まるバカが複数いるとは思わんかったわ。w
発端の
>>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;
まだ何も理解していないらしい
>>895 非同期とノンブロッキングの違いを知らないバカは引っ込んでいなさい。
897 :
835 :2014/06/21(土) 01:48:01.43 ID:nSPSSkcc
898 :
デフォルトの名無しさん :2014/06/23(月) 12:37:22.72 ID:XKl4yasN
>>893 TCPのタイムアウトはソケットオプションにないよ、
って思ったら、Linuxではちょっと前から追加になってるのね。
SO_SNDTIMEO, RCVTIMEO はどこに効くのかよくわからん