わかりました。 RasEnumConnectionsで出来ました。 でもこれってADSLなどの環境でもRASPPPoE使われたら、ダイヤルアップと判断しちゃいますよね。 それはどうしようもないか・・・。
>>605 Ras系のAPIで接続に使われてる回線の種類を取得できない?
具体的にはRASENTRY構造体のszDeviceTypeメンバー RASDT_PPPoEになるのはXPのPPPoEを使った場合だけみたいだけど RASPPPoEではどうなるのかむしろ報告きぼんぬ
おまいらスレ違いなのでwin32APIスレ等に行きたまへ
すびばせん、ちょっとすれ違いかも知れませんが、たっているスレの中で一番近い内容だったので、質問させてください。 現在、OpenSSLを実装して、通信しようとしていますが、SSL_connectでこけます。開発は、C言語でWinsockです。 SSL_library_init() SSL_load_error_strings() SSL_CTX_new() connect() SSL_new() SSL_set_fd() SSL_connect() の順序にて、関数を実行していますが、他に必要なイニシャル(SSL_connect前にすべき事)はありますか? 本もWebも調べたのですが、ほとんどのサンプルは、これと同じように書いてあります。 (もちろんconnect()は完了してから、後の処理を行ってます)
sageちっち。もちろんAGE
あー、なんか記憶あるなー、なんだったっけ
よくわからんから手元にあるソースを貼り付け int sd; SSL_CTX *ctx; SSL *ssl; sd = socket(AF_INET, SOCK_STREAM, 0); connect(sd, (struct sockaddr*)&server, sizeof(server)); SSL_load_error_strings(); SSL_library_init(); ctx = SSL_CTX_new(SSLv2_client_method()); ssl = SSL_new(ctx); SSL_set_fd(ssl, sd); SSL_connect(ssl);
>>613 サンクス。
んんー。同じ事やっているんですが動かないです。
なんでだろう?
動かない、ってだけでは殆ど何もわからん。 どこそこの部分でXXなエラーがでるとかなんとか言えよ。 それと通信相手のこともな。(HTTPS鯖か?)
>>615 >>610 のSSL_connectの戻り値が、0で終わります。
それ以前の関数は、全て正常に実行されますので、他にイニシャルが足りないのかなとか思っちゃいました。
相手先は、HTTPS鯖です。
SSL_get_error()で原因をば
linuxのTCP/IPのソケットで、setsockoptでLINGERを指定しています。 l_onoff=1; l_linger=0; この設定でshutdwon/closeをしてもTIME_WAITになるときとならないときがあるんですが、 原因と対処方法が分かる方がいれば、教えて下さい。
619 :
デフォルトの名無しさん :02/09/06 20:06
VBでwininet.dllを使ってプログラムを組んでいます。 httpでユーザー名とパスワードを設定したいのですがどうすればいいでしょうか? 今のところInternetSetOptionを使うのだと言う事はわかっているんですがうまくいっていません。 InternetOpen->InternetOpenUrl->InternetSetOption->InternetReadFile の順でやってみていますが今のところ 401 Authorization Required です。
620 :
デフォルトの名無しさん :02/09/06 21:10
JavaでURLクラスとHttpURLConnectionクラスで接続すると User_AgentがJava1.3.1_02になるんですが、 これを変更するにはどうしたらいいですか?
621 :
デフォルトの名無しさん :02/09/06 21:33
VBなんですけど、IPアドレスを指定してそのネットワークカードのMACアドレスを取得する方法や関数は、ありませんか?
622 :
デフォルトの名無しさん :02/09/06 22:05
>>621 パケットを解析すれば良いのでは?と思うんですけど。
間違ってたらごめん。
自PCの?それとも他の?
>>622 え、どうやるんですか?厨な質問すいません。。これでも専門学校生です
>>623 他のマシンのMACアドレスです
626 :
デフォルトの名無しさん :02/09/07 09:51
>>624 とりあえず調べたことある。そのときに
HttpURLConnection.setRequestProperty( "User_Agent","agent");
ってあったんだが、そうすると
User_Agent: Java1.3.1_02
User_Agent: agent
の二つ出てくるんですが
>>626 というよりも自分の環境を列挙しないと
誰も答えてくれないよ。
629 :
デフォルトの名無しさん :02/09/07 11:34
>>621 VBにはねーだろ。arpコマンドの出力を加工すれば?
同じサブネットのやつしか取れないけどな。
632 :
デフォルトの名無しさん :02/09/08 08:22
Winsockで非同期でスレッドを使ったマルチクライアントに対応した サーバープログラムのサンプルってないですか?
青い背表紙のゴツい本があったきがする win32 ネットワークプログラミング みたいな
samples\netds\WinSock\iocp とかではいかんのか?
635 :
デフォルトの名無しさん :02/09/09 16:09
WindowsPCにLANカード二枚さしてローカルルータにしたいのですが どのようなソフトがあるでしょうか?
このスレ的には 「そういうソフトをつくれ」 になるわけだが。
>>636 そこのところを、なにとぞよろしゅうお願いします。
>>638 さすがです。さんくす。氏ぬのはかんべんしてね☆
640 :
デフォルトの名無しさん :02/09/13 02:00
netstatに加えてアプリケーション名まで表示するプログラムを作ろうとしています。
(TCPViewのようなもの:
http://www.sysinternals.com/ntw2k/source/tcpview.shtml )
LocalAddress/Port、RemoteAddress/Portまで取得できています。
このコネクションを確保しているアプリケーションを特定する方法はあるでしょうか?
ターゲットはWindows2000です。
(WindowsXPのAllocateAndGetTcpExTableFromStackみたいなのが欲しいのですが……)
641 :
デフォルトの名無しさん :02/09/14 06:26
Winsockで、あるスレッドがgethosybyname()を呼び出しているとします。 この呼び出しをほかのスレッドから強制終了させることはできないでしょうか? やはり、TerminateThreadとか使わないといけないんでしょうか?
ありませぬ gethosybyname そんな関数はありませぬぞ
おたわむれを
gethostbynameが正しいです
よいでわないかよいでわないか あの、長ったらしい非同期の方をつかいなはれ WSAなんとかの方。 WSAAsyncGetHostByNameぞなもし?
UNIX ネットワークプログラミング Vol.3はもう出ないんですかね
せめて遺稿だけでも だめ?
649 :
デフォルトの名無しさん :02/09/16 03:56
自分のホスト(ADSL)のグローバルIPアドレスを取得したいんですが、 簡単な方法ありませんか? (正攻法だとローカルIPアドレス(192.168.〜とか)しか取得できないみたいなんで) TAの設定見に行くしかないでしょうか?
そんなん、つながったIP返してもらうような鯖に つないでみて、教えてもらうしなないでしょう。
>>650 ありがとうございます。
検索してもその方法か、TAの設定ページ見に行く方法しかありませんでした。
(後者は機種限定の様で。)
どっちにしてもプログラムで扱える様に加工しないといけない様です。
めんどっちいのでまたの機会にします。
>>649 # traceroute -m 2 www.2ch.net
の結果を加工。
653 :
デフォルトの名無しさん :02/09/16 18:27
win上でC言語でTCPを使ってデータの受け渡しをしたいんですが send()やrecv()って文字列で送受信するように決められてるらしいのですが それ以外はintとかおくるにはどうすればいいのでしょうか? intでしていてcharでキャストとかやってみたんですがどうもできないみたいで・・
> send()やrecv()って文字列で送受信するように決められてるらしいのですが 歴史的事情からchar*になってるけど、実際はバイト列と思ったほうがいいです
実際の値を指定しているに
656 :
デフォルトの名無しさん :02/09/16 18:34
>>653 文字列じゃねぇよ。バイト列だ。
int value=123;
send(socket, (char*)&value, sizeof(value), 0);
でやれ。
被ったスマソ
htonl等、ネットワークバイトオーダーの考慮も忘れずに。
>>658 ホストバイトオーダーが同じホスト同士だったらいらんよね?(一応確認
>>654-659 みなさんレスありがとう!!
int brf[100]
send(socket, (char*)&buf, sizeof(value), 0);
でいけるでしょうか?ためす環境がなくて・・・。前このようなかんじでやってできなかったもので
int brf[100]じゃなくて int buf[100]でした;; 超ド級初心者でごめんなさい・・・
受け取る方がちゃんとしてれば多分いける。 つっかsizeof(value)じゃなくてsizeof(buf)だな
受け取る方も int buf[100] send(socket, (char*)&buf, sizeof(buf)0); みたいなのでいいんでしょうか? かなりばかなしつもんかもしれないんですがcharは8バイトでintは32バイトぐらいで違うと思うんですが 大丈夫なんでしょうか?
まず、アドレスやポインタの概念を勉強したほうが良いと思われ
>>664 あ,
>>663 も見れ。
>charは8バイトでintは32バイトぐらいで
?????????????????????????
解説 int a[2] があったら,内部では ______________ |0123|0123| ~~~~~~~~~~~ ↑a[0] ↑a[1] となっていると考えれ。そんで, (char*) aとすると, __________________ |0|1|2|3|0|1|2|3| ~~~~~~~~~~~~~~~ となると考えよ。
>>662-668 みなさんこんな僕にレスありがとう!!
668さん丁寧な説明ありがとう、じゃーデータの損失とかはなく、気にしなくていいってことですね!
勉強してるんですがおいつかなくて;;;
670 :
デフォルトの名無しさん :02/09/16 18:59
>>669 >データの損失とかはなく、気にしなくていいってことですね
そうだ。値のキャストとポインタのキャストは違うと思え。
値のキャスト: キャスト先のバイト数に合わせられる
ポインタのキャスト: キャスト先のポインタ型であると”見なす”
>>672 初心者に教えるには最適だと思うが,何か?
-
>>669 TCP ならデータの損失 (欠落が正しい) は無いと思っていいが、送信元が
10バイト送っても、受信側で 9バイトしか受信できない時があるから気をつけて
ね。残りの1バイトは、もう一回受信すると読める。当然逆 (送信元が 10バイト
2回送ってるのに、受信側で 20バイト読める) もあるからね。
昔、ちょっとはまった事あり。
>>675 たぶん
>>669 で言ってるのは話の流れからしてキャストによるデータ損失のことだと思われ。
あ,でも
>>675 の言ってることは大事なことなので言うのは良い。
>>669 へのレスではなく653さんへのレスなら正しいのだとおもう
本をみてたのですが送受信のサイズのところで send()ではstrlen() をつかっていて recv()ではsizeof() をつかってるみたいなんですがこれってどういうことなんでしょう?
>>675 そうゆう場合はMSG_WAITALLを指定するというのも有なのでは?
ブロックしていいなら
>>678 単に受信データのサイズが可変長だからバッファのサイズを指定してる
だけなのでは?
どうもこうも。通信仕様で決めたオフセットにあるデータサイズを受信しないとだめだよ。 その本のsizeof()は恐らくC/Sが完全に同期をとってやりとりしてんだろうけど。
両方sizeof()じゃーだめなんでしょうか?
strlen()だと \0 までのサイズだろう? バイナリデータだと途中に \0 が入ってるかもしれないだろう? そういうこった。
send()は送信データのサイズを指定 でrecv()は受信データを書き込むメモリのサイズを指定 だからrecv()のとこでオーバーフローしなければいいんで ないかな? でもなんでsizeof()にこだわる必要があるのですか
sendにstrlenを使うのは、実際に送る長さを求めるため。 recvにsizeofを使うのは、受け取れる最大長を指定するため。 freadやfwrite使った事ある?
>>682 char str[1000];
strcpy(str,"12345");
の時,
send(socket,str,strlen(str),0) // 5バイト送る
send(socket,str,sizeof(str),0) // 1000バイト送る
だ。
sendにsizeof()使ったでも構わんが,それは意図した動作かどうか良く考え。
何か最後日本語めちゃくちゃでスマソ
結局send()には実際に何バイト送りたいかを指定するのだ。
>>686 の例で,実はstrがバイナリデータで,1000バイト送りたいのならsizeof(str)だ。
だからさー。 char str[1000]; strcpy(str,"12345"); int len = strlen(str); send( sd, &len, sizeof(int), 0 ); send( sd, str, strlen(str), 0 ); だってばさー。ウケ側は recv( sd, &len, sizeof(int), 0 ); recv( sd, str, len, 0 ); だっつーの。
>>688 送られてくるサイズ分かってたらいいでしょ?
653を混乱させたいわけ?
いや、別に混乱させたいワケじゃなくって。 送信時にstrlenっつーことは固定長じゃないでしょ? それに send( sd, str1, strlen(str1), 0 ); send( sd, str2, strlen(str2), 0 ); ってやられたらどーすんの?
653さんはなんとなくrecv()の方で混乱しているのでは?
>>683-688 みなさんありがとうございます。おかげで理解できました。
たとえば
int buf[1000]
で1から1000まで順番にいれてそれをおくりたいんですが
send(socket, (char*)&buf, strlen((char*)buf),0);
受信側では
int buf[1000]
recv(socket, (char*)&buf, sizeof(buf)0);
でいけるんでしょうか?今ためせなくて・・・
まちがってるところあるでしょうか?
あ、すいません&は抜きでおねがいします
バイナリでintの値を送るなら全部(sizeof(buf)分)sendしろ。 intの値に256とかが含まれてたらstrlenじゃだめ だから、write/readとおなじなの。
本では文字列を打ち込んで送るというプログラムでした。 それを計算して数値を送るというのに変えたいと思っています。 本では文字列を打ち込むので長さがわからないということでstrlenをつかってたみたいですね。 数値を送る場合はstrlenは使わないほうがいいでしょうか?strlenはNULLまでのサイズということなら。 日本語おかしくてすいません;;;
んー、まぁ、今の練習(だと思う)の場合はソレでもいいよ。
でも、
>>690 で書いたように連続でなんか送ってきたり、
一回のrecvで到達/受信しきれないデータがきたりするんで、
早いトコ慣れて、通信仕様(今の場合先頭のsizeof(int)に電文長が収まってる)を決めて
やり取りすることを憶えた方がいいよ、絶対。
もっとさ、基本的なファイル入出力とかそういうの、わかってる? ネットワークの送受信もその応用なんだけど、そこまでいってないような。
send()したデータが一回のrecv()コールで読み出せないこともある
>>675 さんがもういってるけど
>>690 あ,マジレスだったのね。スマソ。
>send( sd, str1, strlen(str1), 0 );
>send( sd, str2, strlen(str2), 0 );
>ってやられたらどーすんの?
いや,十分分かってますよ。
でも,プロトコルが区切りを含んでいるやつなら別に構わんでしょう?
例えばHTTP。
>>694-700 ありがとうございます。ほんと助かります。今周りに聞く人がいなくて;;;
通信仕様覚えた方がいいですね。一回で送れたりできたないってのが僕にとってはかなり壁になりそう;;;
がんばってみます。ありがとうございました
>>690 > send( sd, str1, strlen(str1), 0 );
> send( sd, str2, strlen(str2), 0 );
> ってやられたらどーすんの?
どーすんのって、どうしようもないよ。
HTTPでもContentLengthまでは無理矢理読んで、 \n\n以降はContentLength長読む、ってカンジだよね。 もちろん、プロトコルが区切りってのも分かる。
一回で送れないとか、まとめて読み出してしまうとかは まだ気にしなくてもいいかもしれない
>>705 そうだね。
多分そのうち653から
「○○バイト送ったはずなのに届いたデータが足りないんですぅぅぅ!!」
という質問が来るに1000パケット。
意味がわからない 意味がわからない
「意味がわからない」と泣き出すのに10000トランザクション
漏れの方が泣きたいです
結局ネットワークプログラミングの話題ってこればっかりなんだよなー 奥が浅いよなー
スレッドの同期も絡めた話まで発展させりゃいいんだろうけど、 マルチスレッドのスレッドが別にある罠
低層の技術としてはこんなもん。 重要なのはセッション層より上の手順。
OSIモデルって違和感あるんですけど
TCP_KEEPLIVEオプションがインプリしてあるシステムってあります? 相手からのcloseではなく途中の障害で切断された場合の検出に SO_KEEPALIVE使用するんですけど、検出に2時間っていうのが 一般的にTCPのコネクション切断を知る手段って?
自分で勝手に「2分間応答がなければ切断されたものと 見なす」みたいなルール決める。
TCP_KEEPALIVEの間違いですた tcp_keepidleの値を変更すると、システム全部に影響が出るんで それは避けたいなっと
718 :
名無しさん@接続しっぱなし :02/09/17 14:34
>>701 > 一回で送れたりできたないってのが僕にとってはかなり壁になりそう;;;
んな奴がTCPでsend/recv使うんじゃね─よ。
シングルタスク、同期通信なら、fwrite/freadで十分だろ。
> 通信仕様覚えた方がいいですね。
全世界共通規格としてのプロトコルと、
あんたのアプリ間通信の局所的取り決めを区別出来るようになりな。
>>713 TCP/IPプロトコル群のレイヤー構成にピッタリマッチしなくても、
>>653 は一度レイヤーに付いて学んでおく必要があると思うけど、どない?
つか通信プログラムに手をつけるのが早いような気がする・・・
外出だが,通信より先にI/O関係を覚えたほうがいいね。 #っていうか通信って結局I/Oだし。ソケット使えばファイル操作とほとんど同じだし
>>718 さんのいうことは
>>653 さんに限らずという気がします。
それとは別の話としてまずUDP使ったサンプルとか、
エコークライアントとかでTCPダンプしたほうが理解が早い。
きっと。
一度のwriteで全部書けない、というのが現実にバンバン起こるのは socketが初めての人が多いきがする。
writeは全部書けるっつーの。
相手がファイルでも、書ける事は保証されてないでしょ。 相手がソケットなら確実に保証されてない。(Win系はWriteFileね)
正直write()で指定したサイズ以下の書き込みができないのは FIONBIO指定&ネットワーク上に負荷かけたとき位なのでは?
sendもwriteも送るっつーの。 エラーのことをいってんのか?
・・・サイズ以下の書き込みしかできないのは・・・ ですた
ディスクフルとかの時は一度限界まで書き込んで(指定以下のサイズを書きこんで) 次のwriteでエラー(-1)が返るんじゃないの?知らんけど。
ソケットに割り当てられているバッファが限界になると起こります。
send()において「全部は書きこめなかった」が起こるのは間違いない。 でも、write()は動作が違うのかね?
-1が返る
当然write()でも全部書き込めるとは限りません。 指定サイズがかけなくても1byteでも書き込めた場合は-1にはならない です。
結局、
>>722 -の流れで、653を笑えない奴等がいかに多いか分かったよ。
いつからこんなにレベルの低いスレに(w
>>716 できるなら、障害によるものか単にデータの送受信が無いだけなのか
で処理を分けたいのです。
かといってアプリケーションが周期的にデータを送信してみるというのも
ちょっと違う気がしています。
4096byte以上を書き込むと発生する気がします
>>736 select()で調べないのかい?
select()==-1 通信エラー
FD_ISSET(sd)==false 届いてない
FD_ISSET(sd)==true 届いてる
→recv() == -1 なにがしかのエラー
→recv() == 0 切断された
→recv() > 0 正常読みこみ
初心者が見るとわけが分からないだろうから書いておく。
>>723 ,
>>727 はアフォ
>>722 は言いたいことが良く分からない。programmingに依ると言いたいのか?
>>731 の二行目の文は曖昧。
>>731 はどういう時に起きると言っているのか不明。それについて
>>733 は正しい。
ちなみに
>>726 のようなシステム仕様を勝手に想定するのも良くない。
もちろんマニュアルにそう書いてあれば良い。
>>737 相手のプロセスが異常終了した場合はTCPがFINを投げてくれるので
select()で判断できます。
ネットワークの障害でデータが送られてこないのか、クライアントが
ぼけっとしてるだけなのか分けて処理したいのです。
ネットワークの障害ならコネクションの切断とサーバのリソース開放に
もっていって、それ以外ならつなぎっぱなし。
それをアプリケーションが監視しないで済ませようと。
>>739 それはちょと無理じゃないか?
普通はタイムアウトで検出じゃない?
>>740 そのタイムアウトというのが問題でして、SO_KEEPALIVEオプションで設定
すると、2時間かかるのです。
この2時間を短くするのは可能なんですけど、システム全ソケットに影響が出て
しまうという。
で、これをソケット単位で設定するTCP_KEEPALIVEというオプションをサポート
している処理系を探しているのです。
>>740 すみません。
いってること勘違いしました。
アプリでタイマを持つのではなくTCPのレイヤでってことで。
>>743 さん
そゆうのです。
>>744 さん
役に立ちました。
なぜかlinuxは実装してないと思い込んでました。
取り敢えず良かったです。 Winsock(Windows)には実装されてないですねぇ。
>>746 winsockって使ったこと無いんですが、大きく違うものなのですか?
>>747 いや,基本的にBerkeleySocketそのまま。
だけどオプションとか関数とか色々削減されてる。
まあ普通(?)に使う分には大丈夫。
で,WSA*()っていうWindows独自の関数がたっぷり。
別にSO_KEEPALIVE使わなくてもselectでタイムアウト判定すればいいじゃん
>>640 わかる人いる?
なんか最近公開されたAPIでできたようなできなかったような…記憶が微妙。
751 :
名無しさん@接続しっぱなし :02/09/18 06:25
>>748 いや、SO_RCVTIMEOとかWinとSolarisくらいしかない(当時w)のもある。
2000+Winsock2だと、PC-UNIXよりも非同期等が豊富。
>>741 は、KEEPALIVEってどういうものか分かってるのかなぁ?
>>749 のやり方との違い…説明できるだろうか…
>>739 > ネットワークの障害でデータが送られてこないのか、クライアントが
> ぼけっとしてるだけなのか分けて処理したいのです。
超能力があるのなら、ネットワークもコンピュータもいらないじゃん。
752 :
名無しさん@接続しっぱなし :02/09/18 07:01
>>751 >いや、SO_RCVTIMEOとかWinとSolarisくらいしかない(当時w)のもある。
>2000+Winsock2だと、PC-UNIXよりも非同期等が豊富。
あ,そうだったのか。知ったかぶりしてスマソ(恥
>>753 いや、95+Winsock1だと
>>748 のような感じだからいい(w
Winsockといってもピンキリな状況。
しかしより問題なのは、
同じ関数でもWinとWinsockの組合わせで振る舞いの仕様が違うこと!
互換ライブラリなし。アプリごと、マイミドルウェアごとに互換部実装!
version upごとに単調に機能が増えるだけならいいのだが…非連続性が…
この話題は理解度を知るのに便利だね〜 「ソケットへのwriteは送信バッファへの書き込み」 ということに気づけばそんなに難しい話じゃないんだけども。 733の言うようにwriteの戻り値は書き込んだバイト数になります これはファイルでも同じなんですがね・・・ ただし、Javaとかいうタワケた環境では取得不可能(1.4から可能らしい) Javaでネットワークプログラミングを覚えました、なんてもう見てらんない。
>>752 けど、TcpViewや多くのFireWallSoftwareは実現してるから何か方法があるはず……
>>756 んじゃあ、Win2k持ってる奴は、GetProcAddress(LoadLibrary("iphlpapi.dll"),
"AllocateAndGetTcpExTableFromStack" )してみれ
長い名前だなぁ
>>755 >ただし、Javaとかいうタワケた環境では取得不可能(1.4から可能らしい)
単に取得不可能なんじゃなくて、全部書き込むか失敗するまで復帰しない。
普通はJavaの仕様の方が扱いやすいが、シビアな状況では困るかもね。
760 :
デフォルトの名無しさん :02/09/19 11:32
>>757 Win2kのiphlpapi.dllがexportしてる関数くらい調べてから書いてるさ
Javaのタワケっぷりに笑った センス悪すぎ
763 :
デフォルトの名無しさん :02/09/19 23:27
あげあげ
>>751 >>741 は、KEEPALIVEってどういうものか分かってるのかなぁ?
>>749 のやり方との違い…説明できるだろうか…
わかっていないのは、あんたの方。要は、データのやり取りが非常にまれにしか
ない状況で、例えばケーブルが切れたことを即座に検出したいんだと思う。
>>749 の方法だと、例えば1日一回しかデータのやり取りがないと最悪丸一日
そう言う障害に気付かない。そう言うのが困るって言う状況もあるよ。
>>739 >> ネットワークの障害でデータが送られてこないのか、クライアントが
>> ぼけっとしてるだけなのか分けて処理したいのです。
>超能力があるのなら、ネットワークもコンピュータもいらないじゃん。
相手マシンでプロセスがバンバン動いている時なんかは、クライアントはあまり
動けないけど、TCP スタックは動けることが多い。(もちろん実装によるけどね。)
だから、超能力なんか使わなくても回線が切れているか、クライアントの応答が
ない事ぐらいはわかることが多い。
... ぐらいのことは、普通のサーバー管理者なら常識。サーバーの負荷が結構高く
ても、ping には応答すれば TCP層までははまず大丈夫と判断できる。
と、言うことでプログラムで、繋いでいる相手に ICMP Echo パケットでも投げる
のがいいかと...。
>>764 は?
わかってないだろ。
そもそもKEEPALIVEはアプリケーションのTIMEOUT用に使うものではないし。
アプリケーションは好き勝手にポーリングシレ
ちなみに後半の管理者の常識とやら始めて知りました。
世の中便利になりましたね。(w
都合良くトラブルの原因が分かる場合ばかり考えるのではなく、 何の音沙汰もなく何が何やら分からないって状況が起きる可能性が ネットワークでは常にあり、それに対する対処方法(*1)が、 個別にやっていた「都合の良い場合」ほとんど全てを 同時に解決してしまうことに気づくことが、 ネットワークプログラマへの第一歩です。頭の転回が必要になります。 また*1)を行なわないのは、どんなに「特別な場合に」良い振る舞いであっても、 最悪の時が酷すぎるという意味で、『糞』ネットワークアプリケーションです。 局面ごとに適当なtimeoutを用意すること、socketのEOF, errorを見張ること、 application layer heartbeat packetを撃つこと、などなどが肝要で、 また基本中の基本です。
ICMP PacketはFirewallでdropされてしまいますた。
HTTPがコネクションレスなおかげか、そのへんのノウハウは失われつつあるなー
HTTPでもKEEPALIVEあるよ
あ、コネクションレスじゃなくてステートレスだった ごめん
とりあえず後始末しときます。
SO_KEEPALIVEで全部が救えるわけではない。
ハーフオープンコネクションが残るのを避けることができるだけが
正解なので
>>739 の発言は間違い。
また、クライアントのポーリングをアプリでやるか、KEEPALIVEを
使うかは好みの問題とかそんなレベル。
>>739 はTCPのコネクションの監視はTCPでやりたいだけ。
ただ、
>>764 の
>そもそもKEEPALIVEはアプリケーションのTIMEOUT用に使うもの
>ではないし。
に関しては意味不明
> また、クライアントのポーリングをアプリでやるか、KEEPALIVEを > 使うかは好みの問題とかそんなレベル。 うーむ、そうなんですか。時代は変わった… > >そもそもKEEPALIVEはアプリケーションのTIMEOUT用に使うもの > >ではないし。 > に関しては意味不明 意味不明も何もそのままの意味では。 keepalive がアプリケーションの timeout に使えるようになったのは timeout 時間が変更可能、しかもコネクションごとに設定できるようになってからでそ。
TCP Keep-Aliveだけじゃあ、peerのアプリケーションが、 socketを捕まえたままハングアップしているのを、検知できないです。 対応できる状況が「より包括的」で、健全な仕様を設計できるのは、 アプリケーション層でのタイムアウトやハートビートです。 実際シリアスなプロトコルは良くNULL requestを用います。(e.g. NFS等) TCP Keep-Alive方式は、poorな分コーディングも楽ですが、(特に決め打ち時) 局面ごとに違う後始末が必要なアプリケーションで、 SIGPIPEのhandlerの設計が難しくなります。(マルチスレッドだと悲惨) # Winsockでは、直後のsocket操作でWSAENETRESETが返ります。 # このインターフェースもよりpoorな分だけ、コーディングが楽ですね。 また、Keep-aliveはTCPに必須ではありませんし、有害という議論もあります。 (RFC 1122[HR RFC], RFC 1127) 最初からアプリケーション層でやれば、 socket FAQ, Stevens本、RFC 1122,1127のややこしい議論を読まずに済みます。 結局TCP Keep-Aliveは銀の弾じゃない、初級者にはそう見えるようですが。 リモートの様子は全然分からないけどタイムアウト起きちゃった、 この事態と考えを「完全に」受け入れましょう。それが近道です。
> 結局TCP Keep-Aliveは銀の弾じゃない keepalive/timeoutに依存するコードは書かないなあ OSによっては変更不可能だったりするし
775 :
デフォルトの名無しさん :02/09/21 10:57
>>760 おれ、そろそろ「シビア」なことを理解しなきゃならんかも。
Publish/SubscribeなC/SをJavaで設計することになるかもしれない。
大規模になったときに発生しやすい障害とか、そういう勘所がぜんぜん予想できない。
Pub/Subの管理なりパケットの設計なんてのはいいとして、
例外のクラス構成や障害対策をどのように考えておけばよいかがサパーリ。
基本として最低限対応しておくべき事項って何だろう。
>>772 > keepalive がアプリケーションの timeout に使えるようになったのは
> timeout 時間が変更可能、しかもコネクションごとに設定できるようになって
> からでそ。
アフォですか ? 相手アプリケーションが無限ループなんかでハングアップしてて
も、Keepalive はタイムアウトしないことは知ってるのか ? そもそも、Keepalive
って誰が返すかも知らんのか ?
アプリケーションのタイムアウト監視と Keepalive じゃ目的が違うぞ。
>>777 『Javaマルチスレッドプログラミング』は既読なんですが、読めばまた発見ありそうですね。
もいちど読んでみます。
>>775 > Publish/SubscribeなC/SをJavaで設計することになるかもしれない。
冗談だろ?やめとけ
承知の上で、キープアライブ機能はTCPに属すると考えてる派なので KEEPALIVEを使用します。 当然、アプリでも処理してます。 ご意見どうもでした。
たしかFreeBSDではKEEPALIVEの設定が無視されるよね
設定するとエラーが返ってくる?
>>781 指定に関わらず常にKeepAliveはONだよ
785 :
デフォルトの名無しさん :02/09/22 22:51
>>784 本当? それ、RFC1122に違反してるね。
FreeBSD、インターネットに繋げないや…
結論:FreeBSDはゴミ
>>784 > 指定に関わらず常にKeepAliveはONだよ
情報ソースは ?
788 :
デフォルトの名無しさん :02/09/23 00:49
Winsockの質問です。 Winsockを使って、インターネットからHTMLファイルをダウンロードするソフトを作っています。 全体的に実装の方法は分かりました。 で、実際、作って動かした所、自宅のネットからは動くようになりましたが、 会社のLANを伝って、インターネットに接続する場合は、最初の方でGetHostByNameで失敗します。 LAN内のサーバにあるページをダウンロードはできるのですが、どうしてもインターネットからは できません。 おそらく、LAN内にあるProxyサーバが原因だと思いますが、Winsockを使う場合、どうしたらいいのでしょうか? また、何が原因なのでしょうか? (Wininetも使って実験してみた所、こちらの方では、LAN内でも動くことが分かりましたが、 後のことを考えて、どうしてもWinsockを使いたいのです。)
>>788 Proxy通すんだったら,
まず目的URIに接続するのではなく,Proxyに接続する。
で,Proxyに対して
GET 目的URI HTTP…
を送信する。のだ。
>789 レス、ありがとうございます。 概要としては分かりましたが、実際の方法としては、?という感じです。 一応、流れとしては、今、 WSAStartUp()->Socket()->Connect()->Send()... という感じなのですが、 Connect()の前に、Host名をIPアドレスに変換する必要があるわけですが、 その時に失敗するのです。 仰ることは、Host名→IPアドレスの時に、Host名にProxy名を入れればよいということ なのでしょうか? そして、Send()の時にGETすればいいということなのでしょうか? 参考となるページを教えてくだされば光栄なのですが。。。
>>790 >Host名にProxy名を入れればよいということ なのでしょうか?
そういうことです。
結局,目的地のことは何も知らなくていいです。
ProxyServerにさえ接続できればあとは丸投げです。
参考になるページは・・
http://www.google.co.jp この辺で適当に・・(苦笑
なるほど。 なんとなく、わかりました。 適当に探してみます。(ワラ ありがとうございました。
793 :
デフォルトの名無しさん :02/09/23 02:29
便乗で質問。 socketで多段串で送信したいんだけど、どうやるの?
>>793 多段プロキシに対応したプロキシサーバに向かって
それ用の記述でリクエストを送りつければいいのでは
予想1 次に「delegate以外のproxyでも通じるやり方ってある?」という質問が来る。
しかし、delegateの連結キャラクタがウンザリしてる顔文字に見えるのは俺だけですか
>>799 おれもだ。
間にutuが入り込んでおる
資格板に以下の質問がありました。PGの方ならわかるかなと
思い質問します。これって可能でしょうか?
843 名前:名無し検定1級さん 投稿日:02/09/22 02:47
またこんなこと聞いたら絶対合格無理とか言われそうですが・・・
もし自分のIPを偽れるようなブラウザを自作してfusianasanで2chにアクセスすれば偽のIP表示できたりするんでしょうか?
847 名前:名無し検定1級さん 投稿日:02/09/22 10:46
>>845 いいえ、自分のPCから送信されるIPデータグラムの送信元IPアドレスを偽るようなソフトです。ついでに送信元MACアドレスも。
まだTCP/IP仕組みを完全に理解して無いので、そんな単純なことじゃないかもしれませんが。
TCPは双方向に通信しているので、IPアドレス自体を偽装すると応答パケットが届かなくなり、 その結果connectに失敗して書きこめません。 半年程前にはやったSYN-flood攻撃ツールは実際にこれを行っています。 で、fusianasanで表示されるのはIPアドレスではなくリモートホストなので、 DNSの逆引きに対して(サーバーを自分でたてて)リモホを騙れば出来ないこともないでしょうが、 簡単ではないし、マナー的にもやってはいけないことではないでしょうかね。
>>802 なるほどです。
素人考えですが、Connectだけ正常なIPアドレスで行って
書き込み時のみ偽装IPアドレスで行うなんてことは
できるのでしょうか?
>>802 (802かよ!)
しかも、IPアドレスは保存されてるでしょうから、
問題になった時に追跡できますね。
>>803 出来ないです。つーか勉強足りなさ過ぎ。10年早い。帰れ
>>805 私もできないと思っているのですが資格板にできるって人がいるので
詳しい人がいそうなのでここにきました。
>>807 > ここの894とかの言ってることがわからないんです
>
http://school.2ch.net/test/read.cgi/lic/1030209098/ > TCP/IPのオプションでIPアドレス偽って通信することはできるぞ。
まあ、できるといえばできる。つーか、IP アドレスなんてソフト的に割り当ててあるもんだから、いくらでも変えられる。更に言うと、複数の IP アドレスをひとつの NIC に割り振ることもできる。(WindowsNT系なら5個まで標準でサポートしている。)
MAC アドレスについてもドライバさえ (書け or Hack でき) ればいくらでも偽造は可能。技術的には、複数の MAC アドレスを割り振ることもできる。(ごく一部の NIC を除く。)
ただ上記の TCP/IP のオプションと言うのは意味不明。
また、同一ネットワーク内であれば上記のように偽って通信することはできるが、間にルーターが入っているとネットアドレスの所を変更してしまうとルーターが指定したところにパケットを送ってしまうので、通信はできない。
>>808 それはわかります。自分もクラスタ組んだマシンでIPアドレス書き換えた
通信したことありますから。
でも、今回のは2ちゃんに書き込む話なので間にルータが入るのは
当然といっても過言ではないわけで。
やっぱりできないって結論でよいですよね。
>>810 >そりゃ知らんよ。そいつが、2ch の鯖管かも知れんしね。
むぅ。確かに。
>なんて言ってるぐらいだから、信用できるかどうかぐらいすぐわかると思うけど...。
まだネスペ取得できていない素人なので自信がないのです。
901 名前:894 投稿日:02/09/23 14:04
>>896 >>898 >>899 >>900 偽りたいIPアドレスをAとする
自分のIPアドレスをBとする
相手のIPアドレスをCとする
Bが「Aが送出したパケットをルータBを経由してCに届く」ように設定したパケットをCに送出。
CにとってはAからきたパケットだと認識し、「CからルータBを経由してAに届く」ようなパケットをA宛に出す。
が、実際はルータBを経由しているのでルータBに届く。
これでBがAを装うことができる。
ただし、この機能を使ったパケットは弾かれるのが常識。悪用したくても無理だと思われ。
ありがとうございました。 調べたら-_-はdelegateというサーバでしか機能しない様でした。
ネットワーキングプログラム
ネットワーキングプログラミング
ネッティングワーキングプログラミング
818 :
デフォルトの名無しさん :02/09/24 17:10
ネットワークゴキブリw
819 :
デフォルトの名無しさん :02/09/24 17:16
やっぱりダメか・・
>>814 すごいっす。さんくす。資格板に張ってくるっす。
821 :
デフォルトの名無しさん :02/09/26 10:41
FTP サーバにあるファイルの日付を秒単位で取得するにはどうすれば いいんですか。 普通にコマンド打って取ってくるだけでは、分までしか出てこない。(たまに、時まで。リモート側のファイルの年が今年でなかった場合)
ンなもんサーバーの実装による
823 :
名無しさん@接続しっぱなし :02/09/26 11:15
>>821 > 普通に
とは? modtime(protocol的にはMDTM)使ってるの?
ふと疑問に思ったんだが、処理速度より受信速度が上回ったとき、 溢れたデータってどうなるの? C言語やJAVAだと、入出力系はライブラリがバッファを作るみたいだけど バッファに入る程度ならいい感じに受信してくれるのでしょうか?
>>824 > ふと疑問に思ったんだが、処理速度より受信速度が上回ったとき、
> 溢れたデータってどうなるの?
捨てるしかない。普通は、そうならないように...
1. バッファリングする。
2. 処理速度を向上させる。
3. あふれそうになったら相手にちょっと待て、というような仕組み (プロトコル) をもつ。
のどれかで、対処する。もちろん、1. は、一時的な対処だから、全体的に「処理速度より受信速度が上回る」状況では、結局バッファーがオーバーフローてしまう。
> 溢れたデータってどうなるの? TCPと仮定して: 送り側から見ると、送信キューが詰まる。 そのときselectはwritableを返さない。 あるいは非ブロックソケットならsendが0バイト送信しますたと返す。 だからあふれることはないよ。 Javaのjava.net.Socketは仕様がバグってるからうまく処理するのは 難しいかも。 825はアプリの作り方の話? だったらそのとおりだあね
>>826 > 825はアプリの作り方の話?
> だったらそのとおりだあね
はぁ ? TCP/IP は、
>>825 の 3. で処理してますが...。俺には、
>>826 の方がずっとアプリ寄りの話に見えるが...。(select/send なんて、もろソケットを仮定してるみたいだし..。)
825がアプリでのフロー制御の話に見えるか、 UDPでTCPのエミュレートとかいう痛い話に見えるか、 そこの違いか?
ごめんね質問が曖昧で。
TCP/IPの話なんだけど、
>>825 と
>>826 で
とりあえずイメージが掴めました。さんくす
とにかく
>>824 に言えるのは、
・TCPの仕組みの勉強をしろ。
・IPネットワークの最大努力配送について勉強をしろ。
それがイヤなら、UDPを使ったプログラムを書かないと誓って
ただTCP&socketを信じろ。「いい感じ」にやってくれるから。
ただし古いWinsockでSO_RCVTIMEOを使う時はsocketを信じてはいけない。
以前しつもんさせてもらった者です。 みなさんの指摘どおりつまずいてしまいまして;;; 恥じを承知で質問させていただきます。 クライアントからint型で2000送ろうとしたのですが、一回ではおくれないみたいで 1000ぐらいでとまってしまいます。 以前指摘してもらったことから、もう一度送ればいいとやってみたのですがうまくいかず、どうすればいいのか 困ってます。
send()やrecv()のリターンはどうなってんの? -1の場合、errorはいくつになってんの?
>>831 意味不明。もう少し詳しく書かないと答えようが無い。
・・・多分こんなんでいいんだろうけど。
int sendall(int sock, void *buf, int len)
{
int sent = 0;
while (sent < len) {
int cur = send(sock, (char *)buf + sent, len - sent, 0);
if (cur <= 0) {
return (sent > 0) ? sent : -1;
}
sent += cur;
}
return sent;
}
っと、それ以前の基本的な問題な気がしてきた。 もう一度送ればって、intのバッファを先頭から再送してたりしないよね?
ぐーるぐる。同じ話を何度も何度も。ぐーるぐる。
>>832-834 詳しく書かなくて申し訳ないです;;
833さんのでずばり解決できそうです。recvでも同じようにすればいいんですよね?
一度やってみます。
それから返事遅くなってすいません;;
えーと、最近仕事で出た問題なんだけど、send()の直後にclose()すると、
送りきる前に電文が欠けたりするよ。
>>833 で上手く逝かなかったらその辺も疑ってくだちぃ。
> えーと、最近仕事で出た問題なんだけど、send()の直後にclose()すると、 > 送りきる前に電文が欠けたりするよ。 Apacheは返事のsendの後、相手がcloseするまで30秒ぐらい放置してますね ところで参考までにOSなんか教えてもらえるとうれしいッス
Linux。細かいビルドは忘れた。 相手のcloseをselectなりrecvなりで待つってのが正しいとは思います。 ただ、その仕事での問題として、ソケットライブラリでは、 そーゆーアプリケーション側の問題までは関知してなかったんで、 困ったなぁ、となりました。
ApacheがcloseしないのはHTTP/1.1 or HTTP/1.0+KeepAliveだからだと思うのだけど。 send直後にcloseすべきじゃないってのはそうだと思うけど、 そのためにshutdownがあるのでは。
shutdownしてもダメだったんだよねぇ、そのときは。
む、そうか、すまん。 というか、close時にflushしてくれないってのはやっぱおかしいな。 俺も「そういうこと(環境)もある」とだけは覚えておこう。
そういう環境があるから、Apacheはそれを考慮してるわけだ。
844 :
デフォルトの名無しさん :02/10/03 04:24
>>842 > というか、close時にflushしてくれないってのはやっぱおかしいな。
そりゃおかしいよ。
SOCK_STREAMのセマンティクスを守るために、
TCP socketにはTIME_WAITって状態があるんだから。だから、
>>840 > send直後にcloseすべきじゃないってのはそうだと思うけど、
なんてことはない。引き続く送受がなければいきなりcloseしてよい。
> そのためにshutdownがあるのでは。
違う。> 「そのために」
Socket FAQを読むべし。いじょ
846 :
デフォルトの名無しさん :02/10/05 03:01
今windowsでC言語でTCPプログラミングしています。 接続できたあと、スレッドをつくり、一つのソケットで送信、受信を同時にしても大丈夫なのでしょうか? やっぱりまずいんでしょうか?
847 :
デフォルトの名無しさん :02/10/05 03:05
まずい
>>846 ファイルハンドルやコンソール出力に同じことをしたらどうなるか
想像してみれ。
ファイルハンドルへの読み書きは問題ないだろ…
コンソール出力からの受信って何だろう…
>>846 とくに問題は無い。
が、ノンブロックモードにする必要があるから、
別のソケットにしたほうが楽だと思う。
あとサーバーから送信する先のポートの問題とかもあるかも。
>>846 スレッド1が受信専用でスレッド2が送信専用ならおそらく問題ない
852 :
デフォルトの名無しさん :02/10/05 10:52
ちょっと聞きたいことがあるのですが、 winMXってP2Pですよね。でも最初検索するときの、 「誰がどのファイル持ってる」という情報だけは、一箇所に集めてて、 最初にそこを参照して、持ってる人見つけて、あとはP2Pでやる、 って感じでいいですか? なんかP2Pで通信する仕組みを考える時って、それが一番問題な気がします 名簿なし、手探りで不特定多数の相手を見つける、って無理な気が
854 :
デフォルトの名無しさん :02/10/05 11:49
>>853 いやオンラインゲームに使えないかなと思って。
自分にはサーバ立てるのは負担なので、P2Pだけでネットワーク対戦
できたらいいなと。
LAN環境とかでやるなら、ブロードキャストで
全部当たればいいと思うんだけど、
大規模、不特定多数になるとそれだと無理じゃないかと思ったので
winmxっつーかOpenNapプロトコルはそんな感じだが。 winmxのWPNとかはそういう仕組みじゃないぞ。
856 :
デフォルトの名無しさん :02/10/05 13:18
>>848 >>849 >>851 レスありがとうございます。
送信と受信をまったく同時にしたらソケットの中で衝突がおきるのかなー?と初心者ながら思ってました。
ソケット2つ作ってそれを同じ相手につなげて送信と受信分けたほうがいいのかなー?
857 :
デフォルトの名無しさん :02/10/05 13:37
recv関数って、相手がsendするまでずっとまってるんでしょうか?
>>857 うん。
ノンブロッキングにしたらすぐ返ってくるけど。
860 :
デフォルトの名無しさん :02/10/05 14:45
>>856 つーか、君勉強足りなすぎ。ちゃんと本読みなさい。
SOCK_STREAMは双方向全二重の信頼性のある通信を提供します。
同じ方向に利用するスレッド間の同期/排他は忘れないでください。
以上の言葉の意味が分かるまでは勉強しないと先でつまずきます。
>>847-848 お前等、まともなネットワークプログラミングなんかしたことないだろ ?
> ノンブロックモードにする必要があるから
馬鹿、そんなことしたくないから「マルチスレッド」にするんだよ。
> あとサーバーから送信する先のポートの問題とかもあるかも。
意味不明だ。具体的に書いてみれ。
ゲーム製作技術板の「ネットゲー作る技術持ってるやついる?」スレ で暴れてたアフォか? > 馬鹿、そんなことしたくないから「マルチスレッド」にするんだよ。 馬鹿、そんな理由でマルチスレッドなんか使わないんだよ。 素人ほどスレッドを使いたがるのはホントだな。 まさか java.net.Socket とかいう欠陥クラス使ってないだろうな。
>>SOCK_STREAMは双方向全二重の信頼性のある通信を提供します。 回線は全二重というのはわかるのですが、送信や受信するときいったんソケットにためてるのかなー?とおもっていまして、 それだと送信パケットと受信パケットが混ざるとだめかなー?と思ってました。 もし一つのソケットでできる場合2つのソケットで送信と受信をする場合と比べてスピードは遅くなるのでしょうか? >>同じ方向に利用するスレッド間の同期/排他は忘れないでください。 これはクリティカルセクションとか、親スレッドが終了するまで子スレッドは終了させないようにするとかということでしょうか? 質問ばかりですいません
>>863 > 馬鹿、そんな理由でマルチスレッドなんか使わないんだよ。
送受信がほとんど絡まないような場合だと、スレッドの方が全然楽。
ノンブロックでポーリングしまくる方がよほど素人だよ。
スレッドもまともに使えねー奴と言うオチか ?
>>864 > もし一つのソケットでできる場合2つのソケットで送信と受信をする場合と比べてスピードは遅くなるのでしょうか?
もちろん状況によるが、普通は物理層がネックになるだろうからあまり変わらないと思う。(Gbit ぐらいになるとよくわからんけどね。)
>>同じ方向に利用するスレッド間の同期/排他は忘れないでください。
> これはクリティカルセクションとか、親スレッドが終了するまで子スレッドは終了させないようにするとかということでしょうか?
クリティカルセクションと言う言葉は関連するけど、「親スレッドが終了するまで子スレッドは終了させないようにする」とか言うのは、全然関係ない。
要は、2つのスレッドが同時に両方とも書き込んだりしないようにしないとダメってこと。これは、別にソケットだからと言うわけじゃなくてファイルだろうがプリンタだろうが同じ。
ああ、やっぱりあっちで暴れてたアフォだったのか。 お願いだから素人はスレッドなんか使うのやめてくれ。 ややこしくなるから。
>>867 > ややこしくなるから。
心配するな、ややこしいと思ってるのはお前だけだから。
ぐちゃぐちゃ書くなら、「何がおかしい」かぐらい書いたらどう ? (まあ、書・け・た・ら の話だけどね)
>>866 >>要は、2つのスレッドが同時に両方とも書き込んだりしないようにしないとダメってこと。これは、別にソケットだからと言うわけじゃなくて・・・
え?これは別々のスレッドで同じメモリへ同時に書き込みはだめってことですよね?それさえ気をつければソケットにはまったく同時に送信、受信できるんですよね?
>>869 > え?これは別々のスレッドで同じメモリへ同時に書き込みはだめってことですよね?それさえ気をつければソケットにはまったく同時に送信、受信できるんですよね?
う〜〜〜ん、なんか微妙に違ってる気がするなぁ。
複数スレッドが同じメモリーを同時に読み出すのは OK だけど、だからと言ってソケットから同時に受信できるわけじゃない。
例えば、2つのスレッドが同時にソケットから読み出す時に、ネットワークら "ABCD" と来たら、
"A", "BCD" とスレッドに渡るかもしれないし、"AC", "BD" と渡るかもしれない。
と言うような話だよ。
送信と受信を同時に行うのは特に問題はない。(ヴァカな、
>>867 には、ややこしいらしいから勧めないけどね。)
>>869 ソケットの送信と受信は別々のものと考えて差し支えないよ。
たいがいのTCPスタックの実装は内部できちんと排他処理してくれてる。
とはいえ実装依存だから、ドキュメントで確認したほうがいい。
あるスレッドが受信待ちしてるときに、
別のスレッドがそのソケットの受信関連のフラグを操作したときの動作は
未定義かもしれない。
普通そんなことしないけど、素人はやりかねないね。
小さい犬ほど良く吠える
>>864 > 送信や受信するときいったんソケットにためてるのかなー?とおもっていまして、
> それだと送信パケットと受信パケットが混ざるとだめかなー?と思ってました。
そんな、わけのわからんことには、なりません。送信バッファと受信バッファは別になってるんで、1つのソケットでちゃんと送信も受信も出来ます。
ただ、ブロッキングモードだと、受信するとき相手から何か送られて来るまで recv で止まってしまうから、止まってしまってたら送信出来ないだろ? だからノンブロッキングモードにするか、送信用のスレッドと受信用のスレッドを分けるか。
って話なんだと思うけど。・・・なんで2つのスレッドが同時に書き込む話になってるので?
>>870 >>871 >>873 レスありがとうございます。ソケット内部で送信バッファと受信バッファが別になっているとは勉強になりました。
今回あるスレッドで送信、あるスレッドで受信というようにしようと思ってました。一つのソケットでいけそうだということがわかりました。
あと、ソケットが一つでする送信、受信場合と2つで別々に送信受信する場合スピードはかわらないのでしょうか?変わっても気にしなくていい程度なのでしょうか?
ソケット内部での送信バッファと受信バッファが可変の場合変わるかなーと・・・かなり想像でしゃべってもうしわけないです。
あとsendで送るとき一定以上の量になると何回かに分けて送らなければいけないと思うのですが、この一回の容量というのはパケットのサイズなのでしょうか?
それともソケットのバッファがいっぱいになったからなのでしょうか?
>>873 > ただ、ブロッキングモードだと、受信するとき相手から何か送られて来るまで recv で止まってしまうから、止まってしまってたら送信出来ないだろ?
こんな知識で、「素人ほどスレッドを使いたがるのはホントだな。」とか言ってたのか、あきれて物も言えんわ。
> 素人ほどスレッドを使いたがるのはホントだな ソケットに限らずこれはあってる。 ソケット方面で言うと、ノンブロッキングモードを知らない奴(Java厨)とか select/pollを使ったイベントドリブンなプログラミングに慣れてない奴とかが こぞって使いたがるんだよね。
Javaのrecvとかって、ノンブロッキングモードないの? ホント?
>>877 ない。マルチスレッドマンセーなので不要、という思想だそうだ。
さすがにその愚かさに気づいたのか、JDK1.4からはnioというのが付いてる。
頭悪いよね。
頭悪いっつーか、正直信じられん。騙そうとしてたりする?
>>875 >こんな知識で、「素人ほどスレッドを使いたがるのはホントだな。」とか言ってたのか、あきれて物も言えんわ。
いや・・・私はそんなこと言ってませんけど。勝手に結びつけないで頂戴って言っても無駄かな。
とりあえずこんな知識で発言してごめんよ。
でも間違ってたら指摘してくれると勉強になって有り難い。
>>877 なかった気がする。でも調べ足りないだけかもしんない。nioは見てないし。
>>874 > あとsendで送るとき一定以上の量になると何回かに分けて送らなければいけないと思うのですが、この一回の容量というのはパケットのサイズなのでしょうか?
> それともソケットのバッファがいっぱいになったからなのでしょうか?
バッファ。
でもブロッキングモードだったら、指定したバイト数を全部バッファに入れるまでブロッキングするから大丈夫。
いや、ブロッキングされるとマズイ場合も多々あるけど。そゆときはノンブロッキングにするかスレッド分ける。
>>874 > あと、ソケットが一つでする送信、受信場合と
> 2つで別々に送信受信する場合スピードはかわらないのでしょうか?
> 変わっても気にしなくていい程度なのでしょうか?
送受信のバッファはそれぞれ別個のものとして扱われるから、
速度の差はないんじゃないかなあ。
最終的にはTCPスタックの実装で決まることだけど、
送受信のバッファの扱いはOSごとに激しく異なってたきがする。
ところで素人素人連呼してるヴァカが一匹居るけど、
いろいろ試すことに価値はあると思うから気にしないでね。
>>879 当然だがselectもpollもないぞ。理由は878と同じらしい。
すべてはnio様の登場でチャラになったことになってる。
>>876 > > 素人ほどスレッドを使いたがるのはホントだな
> ソケットに限らずこれはあってる。
スレッドが適しているところにはスレッド使えばいいし、そうでないところには select とかでいいと思うよ。
もしかして、スレッド使えない方ですか ?
>>883 「使いたがる」と「適材適所」は激しく異なると思われ
>>879 いちおう、ブロックせずに読めるバイト数を返す available() ってのがあるから、(試したことないけど)入力に関してはノンブロッキングもどきが出来るのかもしんない。
887 :
デフォルトの名無しさん :02/10/05 19:36
>>864 > >>SOCK_STREAMは双方向全二重の信頼性のある通信を提供します。
>
> 回線は全二重というのはわかるのですが、
> 送信や受信するときいったんソケットにためてるのかなー?とおもっていまして、
socketと標準入出力ライブラリのハンドルは別です。
前者は全二重だけど、後者は仕様上半二重で構わないです。
そこのところを気をつけてください。(fdopenなどする場合)
888 :
デフォルトの名無しさん :02/10/05 19:44
>>863 > 素人ほどスレッドを使いたがるのはホントだな。
ちょっと分かってきた時に、無駄にpollingや非同期使いたがる奴もいるね。
どれを使うかはバランス感覚の問題だから、人に教えるのは難しいね。
しかし、一昔前に比べると、systemが成熟してきたので、
multi threadによる解決が自然な場合が多い。
初めからthreadの増大が問題になる事が分かっている場合以外は、
multi threadから始めるという方針も悪くないと思う。
> ちょっと分かってきた時に、無駄にpollingや非同期使いたがる奴もいるね。 うんうん、スレッドは本質的には非同期処理だからねえ。無駄だよねえ。 非同期ソケットとノンブロックソケットはまったく別物だから注意しようね。 > 初めからthreadの増大が問題になる事が分かっている場合以外は、 > multi threadから始めるという方針も悪くないと思う。 少なくとも、IOのためだけにthreadを使うのは間違ってるね。 Javaしか知らない困った人は解らないかもしれないが・・・
>>884 >「使いたがる」と「適材適所」は激しく異なると思われ
この発言はあってるけど、それがどうかしましたか ?
俺は、
>>876 がやけにマルチスレッドを気にしてるみたいだから、マルチスレッドの方が書きやすいこともあるよって言ってるだけだよ。
>>886 どこが「アフォ」か書いてみな。あんた見てると、
>>872 が正しいこと言ってるのがよくわかるよ。
>>887 > socketと標準入出力ライブラリのハンドルは別です。
> 前者は全二重だけど、後者は仕様上半二重で構わないです。
正確には、ファイル入出力は半二重 (ファイルポインタは1個しかないからね) だけど、COM ポートなんかだと全二重のシステムもあるよ。
>>888 ほぼ同意。
>>889 意味不明。
>>880 > いや・・・私はそんなこと言ってませんけど。勝手に結びつけないで頂戴って言っても無駄かな。
人違いか ? なら、ごめんよ。ただ、
> ブロッキングモードだと、受信するとき相手から何か送られて来るまで recv で止まってしまうから、止まってしまってたら送信出来ないだろ? だからノンブロッキングモードにするか、送信用のスレッドと受信用のスレッドを分けるか。
の文章は完全に誤解してると思うから、もう少し勉強してね。
必死な奴だなあ
Win2k VC6.0で、 CSocketクラスを使用してサーバアプリを作成しています。 accept後に一定時間通信がない場合、そのSocketをcloseしたいのですが どのようにtimeout等を考えればよいのでしょうか?
スレッドを使いなさい そうすれば救われます
>>892 > 必死な奴だなあ
それしか書けないなら、書かない方がいいよ。アフォみたいだからね。
>>893 > accept後に一定時間通信がない場合
クライアント/サーバー間のプロトコルがわからない (TCP/IP とか言うなよ、そうじゃなくてアプリケーションレイヤーの話だからね) のでなんとも言え。
まあ、普通のクライアントのコマンドに対してサーバーから応答を返すような場合だったら、サーバーが Receive() で待ってる時にタイマー掛けといてタイムアウトしたら切断しちゃえばいいんじゃないの ?
>>895 >まあ、普通のクライアントのコマンドに対してサーバーから応答を返すような
>場合だったら、サーバーが Receive() で待ってる時にタイマー掛けといて
>タイムアウトしたら切断しちゃえばいいんじゃないの ?
レスありがとうございます。
まさにそのとおりです。
accept→Recieve→Sendといくのですが、
acceptしたあとどうタイマーをかけていいのかわからなかったもので。
やっぱりCSocketよりWinSock直でやったほうがいいんですかね
>>896 > accept→Recieve→Sendといくのですが、
> acceptしたあとどうタイマーをかけていいのかわからなかったもので。
もっとちゃんと状態遷移を理解してないとダメだよ。
1. Listen
2. ← Connect
3. Accept
4. Receive
5. ← Send
6. Receive
7. Send →
8. 4. へ戻る...
クライアントのから待ちになるのは、4〜5 だから 4 (=Receive 開始時) にタイマー掛けて、5. (=クライアントからのデータ到着) がタイムアウトしないかみるだけだよ。
> やっぱりCSocketよりWinSock直でやったほうがいいんですかね
ここら辺の話は、CSocket とか WinSock に依存した話じゃないよ。
普通にselectなりpollなりで待てばいいと思うのだが。
>>897 状態繊維まで書いていただいてすいません…。
たしかにそのとおりだとは思います。
CSocketではacceptしたあと、受信可能状態になればOnRecieve()がよばれると思っています。
ですので、OnRecieve()がよばれるまえ(acceptした直後)にタイマーかけておいて
OnReceive()/OnSend()が呼ばれたらそれぞれ処理してタイマーかけなおし
すればよいのでしょうか?
>>899 > CSocketではacceptしたあと、受信可能状態になればOnRecieve()がよばれると思っています。
> ですので、OnRecieve()がよばれるまえ(acceptした直後)にタイマーかけておいて
> OnReceive()/OnSend()が呼ばれたらそれぞれ処理してタイマーかけなおし
> すればよいのでしょうか?
そう言う意味では、MFC 固有だな。スマソ。
とりあえず、接続されたら OnAccept() が呼ばれるから、タイマー掛けて、OnReceive() 毎に再設定でいいと思うよ。
>>900 >そう言う意味では、MFC 固有だな。スマソ。
やっぱそうなんですね。
>接続されたら OnAccept() が呼ばれるから、タイマー掛けて、OnReceive() 毎に再設定
本当にいろいろとありがとうございます。
とりあえずこれでやってみます。
>>895 自分のことだって分かってるんですね(プ
903 :
デフォルトの名無しさん :02/10/06 02:28
>>901 正直、
>>898 のやり方の方が、
非同期イベント処理の健全性を考えないで済むから楽。
非同期型のプログラムを書くには根本的な頭の切り替えが必要。
特に例外処理や後始末やハンドラの登録/抹消において。
最悪なのは手なりの同期/非同期混合型プログラム。地獄を見ることになる。
これはMFCのCSocket or CAsyncSocketとは直接関係ない話な。
>>903 あ、イベント駆動型プログラム、って書いた方が良かったかな。
Windowsに毒されてる痛いヤシがいるようだが、WindwosCE2.12ではマルチスレッドで 書くしかないわな。(もちろんVC++でだけど)
>>902 > 自分のことだって分かってるんですね(プ
やっぱりこの程度のことしか書けないのね。まあ、2ch だからいいけどさ。
マ板に逝けば、仲間がイパーイいるよ。ププッ。
>>903 お説ごもっともだけど、全然有用な情報がないよ。
知識もってるってひけらかしたいだけ ?
こんなことしてはまったとか、具体的に書いてもらえればいいけどさ。
909 :
◆4I/Yf.lDws :02/10/06 22:28
Winsockを使用して、sendで、次のような送信を試みたのですが、少しおかしくなってしまいます。 for(i=0; i<100; i++) { sprintf(toSendText,"%d",i); send(dstSocket, toSendText, strlen(toSendText)+1, 0); Sleep(100); } それぞれのパケットに1組の数字(文字列)のみを入れて送信したいのですが、 受信したものは、「1\02\03\04\0」というように何個かがくっついてしまったのです。 どうすれば、1パケットに1つの数字を送信できるのでしょうか。 どなたか教えてください。
新キャラ登場だね。コテハンにすればいいのに。
何か一人で熱くなってる痛い奴がいるな。
煽りはほっとけよ。
>>909 普通にやるとくっついたり分断されたりします。
for(i=0; i<100; i++) {
sprintf(toSendText,"%d",i);
len = strlen(toSendText);
send(dstSocket, &len, sizeof(len), 0);
send(dstSocket, toSendText, len, 0);
Sleep(100);
}
でどうよ?
そもそも i を文字列に変換する意味はあるのか?特にないのなら
send(dstSocket, i, sizeof(i), 0);
でどうよ?
>>909 > どうすれば、1パケットに1つの数字を送信できるのでしょうか。
無理。自分で、'\0' 見つけて分解するしかない。
逆に、1 と '\0' が2回に分けて送られることもありうるので注意すること。
あと、
> 受信したものは、「1\02\03\04\0」というように
と書くな、0x31, 0x02, 0x03, 0x04, 0x00 と誤解されるぞ。(と言うか、コンパイラはそう言う風に解釈する。)
ちゃんと、1 \0 2 \0 3 \0 4 \0 のように書け。
913 :
デフォルトの名無しさん :02/10/06 22:59
>>909 TCPなんですよね?
if (TCPです) {
出来ません。
TCPはバイトストリームです。
だからパケットを扱えません。// TCPではセグメントと呼びます。
}
それから、sendの返り値をちゃんと見なさいな。
>>911 最後のは
send(dstSocket, &i, sizeof(i), 0);
でつ…。
>>914 「バイトオーダに注意(MSB or LSB)」は追加しないでいいの?
>>909 はカナーリ初心者プログラマだぞ。
>>915 俺もカナーリ初心者プログラマなのですが…。
バイトオーダーは送信元と受信元が同じエンディアンなら
気にしなくてもいいというのは誤った認識でしょうか?
#初心者なら送信元と受信元は同じ環境だと思ったので…。
バイトオーダーを考慮するなら
long hoge = htonl((long)i);
send(dstSocket, &hoge, sizeof(hoge), 0);
ですかね。
バイトオーダーの遥か以前の段階だし、いいんでねぇの? 【方法1】 電文サイズと電文の実体を送信し、受信側でサイズ分受信する 【方法2】 受信側で\0をデリミタとする 以外に方法ってあるかな? つなげなおすとかでなくて。
やはり無理ですか。 やろうとしているモノは、送信側ソフトのスクロールバーを動かすと、 受信側ソフトのスクロールバーがそれにつられて動くという実験をやろうとしていたのです。 実際に動かしてみると、カクカクするので、909で書いたものを実行してみたところ、 値がくっついてしまっていることが分かったのです。 送られてきたモノを分解したら一応はできるのですが、カクカクするんです。 ちなみに、ローカルエリア内です。 VNCという遠隔操作ソフトをご存知でしょうか? あのソフトもTCPを使用しているようなのですが、 上と同じ環境でマウスは非常に滑らかに動きます。 なにか違うのでしょうか。 勘違いなどしているかもしれませんが、教えていただけないでしょうか。
>>917 \0をデリミタにすると,数値そのまま送った時はまずいよね?
0の時デリミタになっちゃう。
>>911 のようにテキストに変換するならいいけど。
分解しないでも分解してもカクカクするなら、別の原因じゃねぇの? まぁ、前者は明らかにマズイんだが。
>>918 明示的にフラッシュすればいいんでないの?
>>919 そらもちろんテキストが前提です。
バイナリ可変長ならサイズ指定が必須でしょう。
>>922 すいません。あなたを侮ってました。
すんません。すんません。(ぺこぺこ
いやそんなあやまられても困るんでばっくれて下さい
アレでないの。 TCP_NODELAY
TCP_NODELAYとrecvでまとめて受信するのはあまり関係ないと思うけど。 DELAYしようがしまいが、受信ソケットには電文は溜まっていく。
? >送られてきたモノを分解したら一応はできるのですが、カクカクするんです。 >ちなみに、ローカルエリア内です。 これの話だけど。
>>916 > #初心者なら送信元と受信元は同じ環境だと思ったので…。
ビクーリな推測に基づく仮定だな。
君の書くプログラムは大丈夫なのか?
っていうかバイトオーダはなるべくネットワークバイトオーダにするのが 理想なんじゃないかな。
>>929 NDRやCDRみたいなのもあるから、それが理想とは限らんだろ。
>>928 なんでやねん。x86Windoesで送信したら受信する方はx86Windowsやないか。
>>925 そうです!
TCP_NODELAYがミソでした!
無事解決しました。
皆さんどうもありがとうございます。
936 :
デフォルトの名無しさん :02/10/08 04:21
シリアル通信用の 便利なライブラリご存じないでしょうか?
>>933 ミソじゃねえよ。偶然くっつかなくなっただけだ。
少しは過去ログ見ろぼけ。
もう◆4I/Yf.lDwsが来てもレスする気がなくなった
>>937 コンピュータの世界に偶然なんてあるのかい?
そもそも、スクロールを実現すんなら、全データの信頼性よりもパフォーマンスが上がればいいんだろ
NODELAYつかって、パフォーマンスが上がったって事は、成功といってイイんじゃない?
ネトゲでデータの信頼性よりもパフォーマンスを重視するのと同じだよ
それにこの場合は送信元も受信元も同じって決まってるんだしさ
>>940-941 もうほっといたら ? 本人満足してんだしさ。
そのうち痛い目見りゃわかるだろ。
なんか、このスレ、あほうが2人でとんちんかんなこと言ってる感じだな。
944 :
デフォルトの名無しさん :02/10/08 21:46
なぜ本人だと?
>>939 はトリップじゃないから、たぶん第三者の煽りだよね。
この文章に騙される人は、健全性と完全性の区別が出来ない人だね。
>>943 とりあえず、しばらく放置じゃないかな?
947 :
デフォルトの名無しさん :02/10/09 03:08
UNIX板のapacheスレで質問したらこっちの方が良いんじゃないのって言われたのでここで質問します。 SSLの通信をProxyに通す場合の手順がいまいち分かりません。 現在以下までは分かっています。 1.クライアントが、プロクシーサーバにCONNECTメソッドでリクエスト 2.プロクシーサーバは、200をクライアントに返す 3.プロクシーサーバは、1.で送られてきたリモートサーバにコネクションを張る この後が分かりません・・・。 クライアントが何か出力しているのは分かるのですが、 それが合計何バイト出力してるのかが分からず、どこの時点でリモートサーバにデータを 送ればいいのかが分からないとか、そういうところで困ってます。 何か分かる方がいましたらひとつ願います。 RFC2616読んだのですが、これに関してあまり書いてなかった・・・。 HTTPプロクシーのRFCは2616じゃないのでしょうか。
proxyを作ってるのか?
クライアント作ってるのか
>>948 なのかワカラン。
情報不足ですんません。 Proxyつくってます。
select等で、ClientからとServerからの書き込みをまって、 書き込みがきたら、その分だけ転送すればいいんでわ?
じゃあ。 SSLで送信されてるなら、それを受信して解析しないと。 それに、その後再びエンコードしてHTTPサーバにリクエスト。 SSL crypto HTTPあたりでググってみれ。
>>947 CONNECTでコネクションが確立したら、あとは
クライアントが送信してきた内容をそのままサーバに垂れ流す。
サーバが送ってきた内容も同様にそのままクライアントに転送。
どっちがいつ送ってくるかは分からないからいつ送ってきても
いいように待つ。
ようするにsocksと同じで汎用のポートフォワーディングの
手段として使えるからちゃんとアクセス制限しないと
セキュリティホールになる。
>>952 SSL Proxyは通信内容に一切関知しない。
Proxyが暗号化を解除できたらSSLの意味がないだろ。
>>951 すんません。
もう少し詳しくと言うかなんか参考文献あったら教えてください。
>>953 あぁ、やっぱいつ送ってきても良いように待つのですか。
一般的なやり方ってどんなのがあるんでしょうか?
スレッドを使うとか?
956 :
デフォルトの名無しさん :02/10/09 16:30
だからー
>>951 が言ってるとおりselect等で待つ。
ソケットの使い方はUNIXネットワークプログラミングVol.1でも読めや。
>>926 TCP_NODELAY を使いつつ、send() 側も recv() 側も、バッファ(第 3 引数)を 1 byte にすりゃいいだろ。 いまさらだけど。
>>926 TCP_NODELAY を使いつつ、send() 側も recv() 側も、バッファ(第 3 引数)を
1 byte にすりゃいいだろ。
いまさらだけど。
959 :
デフォルトの名無しさん :02/10/09 17:29
>>956 Javaで、selectするにはどうすれば良いんでしょうか。
スレッドとTCPのソケット通信について… TCP/IPがマルチスレッドで動いてくれるとでも思っているヤツはバカ!
>>960 OS によっては、ちゃんとカーネル内でパラレルに動作するようになってます けど、バカですか?
947はJavaで作ってるの?
963 :
デフォルトの名無しさん :02/10/10 02:11
>>947 にはJavaなんて一言も書いてなかったな。
まあそれはともかくJavaのJDK 1.3まではスレッド使うしかない。
JDK 1.4ならnio使え。
964 :
デフォルトの名無しさん :02/10/10 06:04
WindowsのTCP/IPドライバのソースを 屏風から追い出してくれたら答えます
そういえば、winsock って、WSAAsyncSelect()を使うと、勝手にスレッドを作るね。 タスクマネージャで確認した程度だから、間違ってるかもしれないけれど。
968 :
デフォルトの名無しさん :02/10/10 15:52
>>968 > ポートフォワーディングすれば
間違えた。
> ポートフォワーディングみたいなこと
に訂正。
ポートフォワーディングって言うよりはトンネリングって言う方が正しいのかな。
OK。Go!
>>968 使い方が分からんってそのまんまじゃん。
もしかしてCのselectの使い方も分からない?
だったらFAQでも読め。URLはちょうどテンプレが
貼られてる。
>>961 へぇプロトコルがマルチスレッドに対応しているのか…どこの世界の話かよかったら聞かせろ。
おまえは、複数の人間がしゃべっているのを同時に聞ける天才か?
>>961 ,960,974
プロトコルとOS話が…は別だわな…
>>974 961はOS の TCP/IPプロトコルスタック部分が並列動作するってことを
簡略な表現で言っただけでしょ。
その程度の省略が自動補完できない時点で、知識レベルが論外って気がするが...
並列動作する実装もありうると想像はできるけど、 実際のとこどうなんだろ。 linuxとか*BSDとかの実装を見た人います?
>>978 IP→TCPのDeMultiplexingを担っているところが、
TCPプロトコルスタック部分の(接続単位から見た)並列動作を実現しているところ。
と言われただけで、かなり具体的なイメージが湧かないと、
ソースの場所示されても分からないと思う。イベント駆動型だし。
ちなみに接続単位から見た並列動作が実現できてないのが、
一昔前のいわゆるパソコン通信です。(接続の多重化が行なわれてない)
いや、実際に複数のコンテキストが"同時に"TCP/IPスタックをまわせる ようになってるのかなあ、と。 実際は排他制御されてたりしない?
>>980 君が書いたら、大域変数バリバリでそうなるのかもしれないけど、
tcp_input.c(の関数群)は、「接続単位」に対してパラメタライズされてます。
> 実際は排他制御されてたりしない?
tcp_input.cの#ifdef CONFIG_SMP調べればすぐ分かるでしょ?
ジャイアントロックないでしょ?
そもそも多重化って意味分かりますか?
全然意味分からないならport 4の図書コーナーにGO!
>>981 どこの実装?CONFIG_SMPってことはlinuxかな。
何にせよ読んでる人がいることに驚いた...
接続単位ってことですが、送受信は分かれますか?
もし分かれるなら、
TCPの送受信で共有しているパラメータ(ブロッキングモードなど)
へのアクセスは正しく排他されますか?
1000Get!!
> もちろん必要最小限の排他は行なってるわね。 そのへんは送受信で共有されてるパラメータによっては 複雑な処理になりそうですね。バグも入りそうだけど、 まあ腕の見せ所なんでしょう。 ところで本当に並列に動作していることを確認した人はいますか? だれも「すると思う」レベルの話しかしてませんし。 難しいのかな。
>>985 > ところで本当に並列に動作していることを確認した人はいますか?
あなたが説明聞いても分からないだけだよ?
本当に並列に動作しているもの。
>>987 > 本当に並列に動作しているもの。
確認方法は ?
横槍ですまんが,並列に動作していないことについての確認方法は?
| |ノノハ |_| 。‘人 |文|⊂) | ̄|∧|  ̄ ̄ ̄ ̄ ̄ | | |_| |文| ノノ サッ | ̄|  ̄ ̄ ̄ ̄ ̄
| | |_| |文| ノノ サッ | ̄|  ̄ ̄ ̄ ̄
梅
ume
ume
ume
ume
ume
あ
__ l⊆⊇`ヽ ≡ ヤホーイ (´D`Lノ ≡ m=○=mノ) ≡ _/_/(「_ノニコ ≡ ( (0)=(__)0) ≡(´⌒(´⌒;;
〜oノハヽo〜 ミ _ ドスッ ( ^▽^) ─┴┴─┐ / つ. 1000 │ /_____|└─┬┬─┘ ∪ ∪ ││ _ε3
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。