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

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

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

1 :デフォルトの名無しさん:03/05/05 12:47
主にソケットに関しての質疑応答スレです。

Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html

Winsock Programmer's FAQ
http://tangentsoft.net/wskfaq/

過去スレ:
Port1 http://pc.2ch.net/tech/kako/970/970344582.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port3 http://pc3.2ch.net/test/read.cgi/tech/1023359282/
Port4 http://pc3.2ch.net/test/read.cgi/tech/1034236536/
Port5 http://pc2.2ch.net/test/read.cgi/tech/1040220302/

関連リンクは>>2-10辺り

2 :デフォルトの名無しさん:03/05/05 12:49
(σ・∀・)σ ネッツ!

3 :デフォルトの名無しさん:03/05/05 12:49
図書コーナー!

UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
詳解TCP/IP〈Vol.1〉プロトコル
http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
The Implementation (TCP/IP Illustrated, Volume 2)
http://www.amazon.co.jp/exec/obidos/ASIN/020163354X/
Linuxソケットプログラミング―ネットワークプログラミングにおける実践技法
http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/

足りなかったら適当に付け足してね

4 :デフォルトの名無しさん:03/05/05 13:07
前スレに出てきたURL抜粋

JPNIC RFC関連リンク集
http://rfc-jp.nic.ad.jp/link/

RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
http://www.studyinghttp.net/rfc_ja/2616/rfc2616_ja.html

C10K ヘヴィーロードサーバ
http://www.kegel.com/c10k.html

TCP/IPによるネットワーク構築〈Vol.3〉―クライアント‐サーバプログラミングとアプリケーション
http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
Webプロトコル詳解―HTTP/1.1、Webキャッシング、トラフィック特性分析
http://www.amazon.co.jp/exec/obidos/ASIN/4894715414

tcpdump
http://www.tcpdump.org/
Windump
http://netgroup-serv.polito.it/netgroup/tools.html
pathchar
ftp://ftp.ee.lbl.gov/pathchar/
pchar
http://www.employees.org/~bmah/Software/pchar/

MSDN
http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp


5 :デフォルトの名無しさん:03/05/05 14:00
Winsock FAQ 日本語訳
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

6 :デフォルトの名無しさん:03/05/05 14:23
RFC-JP ML
http://www.imasy.or.jp/~masaka/rfc-jp/


7 :デフォルトの名無しさん:03/05/05 15:20
>>1
漏ツカレ

8 :デフォルトの名無しさん:03/05/05 16:06
自前のプログラムでWebサイトをアクセスしてるんだけど、
最近BIGL○BEのサイトが応答しなくなったぞ。
FlushGetもダメみたいだ。
情報求む。


9 :デフォルトの名無しさん:03/05/05 16:19
>>8
プロバイダ板(isp)へGO!

10 :デフォルトの名無しさん:03/05/05 23:24
もしかしたら初心者スレで聞いた方が良いのかも知れないのですが、
とりあえずこっちで質問させて下さい。

Winsock1.1である程度組んでしまったのですが、
プロトコルはTCP/IPのみと言う事を前提とした場合
今からSock2に直すメリットはあるのでしょうか?

11 :デフォルトの名無しさん:03/05/06 15:45
>>10
というよりも、
versionに依存しないプログラミングを心掛けよ。
依存せざるをえない部分は可能な限りポータブルにするよう心掛けよ。(wrapping等)
リリースノートの前のバージョンとの変更点を精読せよ。
以上。

ネットワークに関する具体的な要件、条件がないのだから、
以上のようなスレ違いの答えしか書けない。


12 :デフォルトの名無しさん:03/05/06 17:47
大人気ないなあ

13 :デフォルトの名無しさん:03/05/06 18:13
あ、大人気ないってのは、前スレの事ね。

14 :デフォルトの名無しさん:03/05/06 18:46
だいにんき?

15 :デフォルトの名無しさん:03/05/06 18:48
なんだっていいよ

16 :デフォルトの名無しさん:03/05/06 22:12
ひろし人気ないなあ

17 :デフォルトの名無しさん:03/05/07 00:25
誰か教えてください。
むかーしのCマガジンのサンプル見て、
メールを送信するプログラムを打ち込んだらうまくいきました。
WindowsのWinsockです。
でも、よく見ると、そのサンプルは下のようなコードの繰り返しがあります。

sprintf(szBuffer, "MAIL FROM:HOGE\r\n");
err = send(s, szBuffer, strlen(szBuffer), 0);
memset(szBuffer, '\0', sizeof(szBuffer)); //この理由はわからない
recv(s, szBuffer, sizeof(szBuffer), 0);

HELOを送ったりMAIL FROM:を送ったり、でわかるのですが、
errを使ってないなのです。(続きます。)

18 :続きです:03/05/07 00:25
そこで、

void Send(SOCKET s, char* buffer){
int err;
err = send(s, buffer, sizeof(buffer). 0);
if(err == SOCKET_ERROR){
printf("Error\n");
exit(-1);
}
}

みたいのを作って、上のコードを

sprintf(szBuffer, "MAIL FROM:HOGE\r\n");
Send(s, szBuffer);
memset(szBuffer, '\0', sizeof(szBuffer)); //この理由はわからない
recv(s, szBuffer, sizeof(szBuffer), 0);

にしたら、とたんに、メールを送れなくなってしまいました。
(コンパイルもでき、起動もし、正常終了します。)
なんでこうなるんだか狐につままれているようです。
何か、根本的なところで間違っているのでしょうか?

19 :デフォルトの名無しさん:03/05/07 00:35
sizeof(buffer)

20 :デフォルトの名無しさん:03/05/07 00:43
ネットワーク関連の洋書で頻繁に出てくる
[sink]
はどう訳せば言いのですか?


21 :18:03/05/07 00:54
>>19
どひゃー。
はずかしーです。strlenに直したら動きました。
ばかな質問でスレを汚してしまいました。
すみませんでした。
俺という人間そのものが根本的に間違ってました。

ありがとうございます。

22 :デフォルトの名無しさん:03/05/10 11:51
途中に\0を含んでたらどうするんだ?
SMTPではそういうことはないかもしれんが

23 :デフォルトの名無しさん:03/05/10 12:10
>>22
まさしく自問自答。文末は曖昧。

24 :デフォルトの名無しさん:03/05/11 14:04
パソコン通信系の掲示板用ブラウザを作ろうと思ってます
telnetアクセスができるので
telnetでアクセスしてログを取得しようと思うのですが
ネゴシエーション部分の仕様がよくわかりません

IAC DO TERMINAL-SPEED
に対して
IAC SB TERMINAL-SPEED SEND IAC SE
という例がRFC1079にあったのですが

IAC DO TERMINAL-SPEED IAC DO TERMINAL-TYPE ... '\0'
のように送られてくる場合
IAC SB TERMINAL-SPEED ... IAC SB TERMINAL-TYPE ... '\0'
と送り返せばいいのでしょうか?それとも
IAC SB TERMINAL-SPEED ... '\0'
IAC SB TERMINAL-TYPE ... '\0'
でしょうか?それとも他にコードが必要なのでしょうか?

Borland C++ Builder でClientSocketを使っているのですが
そっちの使い方が悪い可能性もあるので
原因がつかみきれていません

他言語でも、参考になるものがありましたらご教示お願いします
よろしくお願いします

25 :デフォルトの名無しさん:03/05/11 18:54
今、簡単なリンクチェッカーを作ってます。
通常、サイトが更新されたかどうかって「Last-Modified」で
判断すると思うんですけど、必ず返してくれるとは限りませんよね?
その場合どうしたらいいんでしょうか?

26 :デフォルトの名無しさん:03/05/11 19:09
>>25
返してもらえないんだったら
どうしようもないじゃん。

27 :bloom:03/05/11 19:13
http://homepage.mac.com/ayaya16/

28 :25:03/05/11 19:41
>>26
Apacheはデフォルトでは「Last-Modified」返さないと聞きました。
返すように指定できるヘッダーとかあるのでしょうか?
通常IEなどのブラウザではどのように処理しているのでしょうか?

29 :デフォルトの名無しさん:03/05/11 19:54
HEADで取得してLast-ModifiedがなかったらGETでページを取得/保存して、
前にGETしたものと比較する。

30 :デフォルトの名無しさん:03/05/11 20:15
>今、簡単なリンクチェッカーを作ってます。
と来て
>通常IEなどのブラウザではどのように処理しているのでしょうか?
IEはリンクチェッカーじゃないし
チェックできないのなら全部読み出せばいいだけ

他人の作った同種のソフトを見ればそんな疑問など
脳味噌の片隅のも浮かばないはずだが
作ろうとするのならその手のソフトの設定項目ぐらい確認しろ

31 :BSDソケ太:03/05/11 20:23
>>25
http://www.studyinghttp.net/rfc_ja/2616/sec13.html#sec13.3
http://www.studyinghttp.net/rfc_ja/2616/sec14.html#sec14.25

テンプレくらい見た方が良いと思われ

32 :デフォルトの名無しさん:03/05/12 06:12
>>28
質問自体からは逸れるが
>Apacheはデフォルトでは「Last-Modified」返さないと聞きました。
なんだそりゃ。
staticなページなら返すよ。
SSIやCGIなんかだとデフォルトじゃ返さないけどね。

33 :デフォルトの名無しさん:03/05/12 07:35
>>32
確かに返して当然だな。

つーか、Apacheのシェアとか考えたら>>28のようなことは
信じられないな。
世の中のWEB Serverの半分以上がLast-Modifiedを返さないことに
なってしまいそうだし。
まあ、まともな鯖管ならデフォルトで使うなんてありえないけど。

34 :28:03/05/12 10:54
今は>>29のやり方でやってるんですけど、ヘッダー情報だけで
なんとかならないかなーと思いまして。

リンクチェックした時にページ毎にLast-Modifiedを保存しておき、
(Last-Modifiedが無ければチェック時の時刻を保存)
次回リンクチェックするときに、HEADで「If-Modified-Since 保存時刻」
を送るというのはどうでしょうか?

35 :28:03/05/12 10:58
>>32-33
嘘書いちゃったようで、すいません。

36 :デフォルトの名無しさん:03/05/12 17:46
レイトレベンチのHPのトップページを見たらActiveXのDLLがUPされてた。
ソケットが使えるようだぞ。
http://www5e.biglobe.ne.jp/~liquor/
サンプル付いてるから、突っ込みよろ。


37 :デフォルトの名無しさん:03/05/12 23:17
>>29
GETでアクセスしてLast-Modifiedがなかったらページを保存して
前にGETしたものと比較すればいい。
どうしてわざわざ負荷を2倍にする必要がある?
(HEADだから2倍までは行かないか)
>>34
HEADにIf-Modified-Since付けるのは禁止されてる。意味ないし。
読めって言ってるだろ(>>31)。

38 :デフォルトの名無しさん:03/05/13 00:05
>HEADにIf-Modified-Since付けるのは禁止されてる。
本当?

39 :デフォルトの名無しさん:03/05/13 00:06
そこらの2Ghzマシンで、1秒間に10回ほど2000クライアント程と50バイトぐらいずつ交換出来ないだろうかと思いサーバープログラムを作成しています。
書籍の「Winsock 2.0」やMSのサンプルを見ながらI/O完了ポートを利用して実装してみました。
データ交換は出来るようになったのですが、サーバーとクライアントを同じPCで実行している時と、他のマシンと分けて実行した時では、ReadFile,WriteFileの処理クロックが変わってしまいました。
後者では倍ほど遅くなりました。
チューニング目的で、接続クライアントの状況が変わるとCPU占有率も変わるのか、それとも単にLANの使用目的でシステムがCPUを使用していたのか知りたくなりました。
LANのチップはSisのマザーにオンチップのRealTechのRTL-8139(A)でOSはWin2kProです。
winのシステム内部にも疎くて、ボトルネックがあるかも分からないのですが、高速化の方法があったら情報を下さい。

クライアントの送受信間にSleepを入れたりしてみましたが、CPU使用率は変わりませんでした。(非同期化はOK?)
クロックの測定はrdtsc命令を使って測っています。
他スレッドが完了ポートキューを見張っていますが、測定ではデータ処理は行ってません。
サーバーからは1クライアントにつき秒間320バイト、逆は秒間140バイト送信しています。
プロセスが別PC上だと、サーバー側では1秒間に100クライアント当たりのRealFile、WriteFile実行に90MClock必要でした。
理由がわからないのですが、1クライアント当たり秒間90万Clock、1通信当たり9万Clockも使用しています。
32バイトを転送し、14バイトの受信を行うソケットの処理に9万clockも必要なんでしょうか?
情報不足の突っ込みお願いします。

40 :デフォルトの名無しさん:03/05/13 00:49
自己レスで申し訳ないんですが、LANカードにインテリジェンスタイプとノンインテリジェンスタイプがあるそうです。
ReadTechのRTL-81xx系はインテリジェンスタイプで、、_| ̄|○
VGAカードのハードウエアT&Lよろしくソフトで頼むと自動でやってくれるようなのがいいですね。
これまでNICの転送量で困った試しは無かったので、、サーバー用途の製品はやはり高価、、ですよね、、すいません_| ̄|○
3COMのGイーサネット辺りを買ったら買ったら改善するでしょうか?
とりあえず、3COMサイトのフィーチャー辺りを調べてみます。

41 :39の人:03/05/13 01:07
それにしても、同PC上で1通信の手続きを行うのに半分の4万5千クロックもかかっています。
バッファのコピーを数回行ったとして、1000クロックぐらいにならないでしょうか。

42 :デフォルトの名無しさん:03/05/13 01:57
いっとくけどTCP/IPは遅いよ

43 :デフォルトの名無しさん:03/05/13 02:09
>>39
1CPUのマシン?
外部との通信がはいったらそれくらいが妥当な性能だと思う。
ローカル内だとWinsock内で片付けられることもあるだろうし。

44 :39の人:03/05/13 03:07
書いてませんでした。
TCP/IPで1CPUです。
「このデータをTCPIPでIP何番に送っといてくださいね、終わったら通知下さい。」とデバイスに頼むようなシステムは無いんでしょうか。
ゲーム会社が何で苦労しているのか分からないので作り始めたプログラムですが、そこらのPCで行うと電気とCPUの無駄ということでしょうか?
分岐ならミスだけでも千回行える数字ですから、数十バイトの送受信にCPUで数万clockもかかるとなると相当に非効率かなと感じました。
でも、こんなこと考えない筈は無いし、きっと出来ない訳があるんですね。
UDPも試してみます。

他にMSのサンプルに書いてあった為ですが、自分でもWriteFile使っているのが気になりました。
WriteFileはファイルについても使用できるようなので、WSA系を使うのが妥当ですよね。(遅くなりそうな予感が、、)

45 :デフォルトの名無しさん:03/05/13 03:40
まさか、1トランザクション毎に接続/切断してないよね?

46 :39の人:03/05/13 05:30
接続型ですので繋いだ後はクライアントが切断するまでデータを通信し会っています。
WSAとReadFile,WriteFileなのですが、結果から言うとWSAが早くなりました。
前者は1秒間に100クライアントと通信して35Mclockでした。
後者は同じ条件で39Mclockでした。
先ほど書いたLANカードはREALTEKでReadTeckではありませんでした。
ノンインテリジェンスタイプで、サポートに苦情がくるのはこれに限るとの評判らしいです。
LANチップが違うPCでも試してみようと思います。

47 :39の人:03/05/13 09:26
VIAのチップが載ったコレガのPCI-TXLがあったので挿して測ってみたのですが、同じチップじゃないのかというぐらい同等の性能でした。
書き忘れましたが、違うPCにクライアントプロセスがあった場合もWSAが同様に早くなりました。
こちらも100クライアントに1秒間辺り80M程度使用していました。
M以下切り捨てで76M(WSA, Clock):80M(R/WFile, Clock)でした。


48 :39の人:03/05/13 15:45
同PC上のプロセスでの数値です。
前の測定はループや分岐の除外を自分で計算していたのであまり厳密でなかったので測り直しました。
前の数値は平均とは言いがたいものでしたので、今回は120秒の合計クロックを割ってみました。
具体的に以下のようになります。小数第3桁を四捨五入しています。
start = rdtsc();
writefile(......)
finish = rdtsc();
diff += finish - start;

かかったクロックなのですが、関数毎に調べました。
ReadFile  4.75M/Sec 100Client
WriteFile 27.65M/Sec 100Client
WSARecv  5.36M/Sec 100Client
WSASend  24.52M/Sec 100Client

セットで、関数のみ測ると
R/WFile    34.1M/Sec 100Client
WSA      29.8M/Sec 100Client
RFile+WSASend 29.4M/Sec 100Client
となりました。
RFileとWSASendを使うとWSAのセットに比べても1.3%処理時間が短縮する訳で、、頭が痛いです。
環境やコンパイラによって変わると思いますが、、。


49 :39の人:03/05/13 18:12
48のプロセスが別PC上の場合です。
ReadFile  8.7M/Sec 100Client
WriteFile 61.2M/Sec 100Client
WSARecv  6.45M/Sec 100Client
WSASend  57.0M/Sec 100Client

セットで、関数のみ測ると
R/WFile    71.8M/Sec 100Client
WSA      63.4M/Sec 100Client
RFile+WSASend 66.2M/Sec 100Client
現金ですがWSAを使えってことでしょう。


50 :デフォルトの名無しさん:03/05/13 19:51
頑張ってるところ素朴な疑問なんだけど、
そこまでスループット気にする処理作ってんの?
単に、技術的な興味があるだけ?

51 :39の人:03/05/13 22:37
技術的な興味もそうですが、高スループットのプログラムは経済的にも有用です。
プログラム全体のスループットが1/2になればサーバーとしては倍の速度のものを使用しているのと同じ事です。
あたりまえですが、存在するCPUの周波数には上限があるので、スループットが上昇しなければそれ以上は処理出来ません。
「処理時間の90%は10%のコードが使用する」と某有名書籍に書いてあるように、その10%をアルゴリズム改良なり、アセンブラなどで最適化を施すと、プログラムが数分の一の速度で動作するようになる場合もあります。
2台で処理するとなると、サーバー本体の代金+電気代(200Wを1年間つけっぱなしだと3万5千円ぐらい)が必要になるでしょう。
管理労力も増えますし、部屋は暑くなりますし良いことは無いと思われます。(冬はあったかかったですが)
今までそういった考えを持たずにやってきたのですが、私の作れるプログラムはヘボで碌に処理をしません。
最近悔い改めてようかと考えている訳ですが、、万策尽きたところでUDPに_| ̄|○

52 :デフォルトの名無しさん:03/05/13 23:05
関数の処理時間測ってもしょうがないような。

53 :デフォルトの名無しさん:03/05/14 06:28
>>38
すまん禁止されてるのはHTTP/1.0だけだった

54 :デフォルトの名無しさん:03/05/14 16:28
NTLM認証のかかったPROXYを超えて、http接続するプログラムを作りたいのですが、
うまく行きません。
なにか、分かるかたいましたら、教えてください。
よろしくお願いします。


55 :デフォルトの名無しさん:03/05/14 16:52
ううっ すいません。
Win上で
int hoge = 1;
ioctlsocket(fd,FIONBIO,&hoge);
以上のようにして非ブロッキングモード(非同期?)にしています。

しかし今現在非ブロッキングモードかどうかを
判定する関数が分かりません。
WSAIsBlocking();
かと思ったのですが結果が違いました。

どなたか博識な方 お教え頂けるとありがたいです。


Linuxの場合は
int flag = fcntl(fd, F_GETFL, 0);
とやってflags & O_NONBLOCKで判定していました。


56 :デフォルトの名無しさん:03/05/14 16:57
>>51
そんなに通信に専念させちゃっていいんですかね。


57 :39の人:03/05/14 18:19
>>52
なんとなく原因個所が特定された訳で、、。
>>56
駄目なんで対策を探していたようで、見つからなかったのでTCP/IPでは諦めたという次第で、、。
100クライアントで60Mっていうのは、直線で負荷が上がったとしても2000クライアントなら既に1.2Gな訳で、、。
どちらかというと計算がメインな筈なので現実的ではないですね。

プログラムをいじらずに情報集めに専念しているところで、「WinSock2.0」のDODモデル辺りの記述を読み直しました。
TCPの機能を見るに、、これだけ遅くて当然かもなと思いました。
WINのTCP/IPを利用するソフトウエアを成り立たせているTCPやIPのルーチンを作成したのもMSな訳ですよね。
NICのドライバーを作成した方なら分かる筈ですが、私は未だNICへOSのインターフェイスがどれだけ提供されているか知りません。
現時点でボトルネックがどこに存在するのか分からないです。
TCPによるデータグラム分割、再送などの時点か、ブリッジやPCIバス経由の時点か、NICの転送能力の問題か。
OSのインターフェイスがTCPで時間が掛かる処理をハードに投げられるようになっていて、かつそういった機能を提供するデバイスがあれば、処理が劇的に高速化するでしょう。
それ以外なら、現在の環境でTCP/IP上で目的を果たすプログラムを作成するのは物理法則を無視しない限り不可能ではないかと。
42,43の方がおっしゃっているUDPで転送にオーバーヘッドが著しく掛からないなら、TCPの機能を果たす時点でクロックを大量に消費していると思われます。
UDPで実装すれば引き算の問題になるので、判明するかなと。
不明としている点で、何か情報があれば教えていただけると嬉しいです。

58 :デフォルトの名無しさん:03/05/14 18:29
クロック・・・

59 :デフォルトの名無しさん:03/05/14 19:32
性能についての要件無しによくやれるなあ

60 :デフォルトの名無しさん:03/05/14 19:44
39の人はどちらかというと既に知的好奇心の域なのでは。
仕事でそれやってると給料減らされる場合もあるけど(w

>>39
ボトルネックは普通のPC(だよね?)を流用してるとこもあるんじゃないかと。

61 :デフォルトの名無しさん:03/05/14 20:15
myrinetってどうやって動いてるんだろうね。

62 :デフォルトの名無しさん:03/05/14 23:22
VBのWinSockコントロールで、
簡単なサーバ側とクライアント側のPGを作成しています。

コマンドボタン1のクリックで、connect
コマンドボタン2のクリックで、データ送信
だと上手く行くのですが、

コマンドボタン1のクリックで、connect→データ送信

とすると、エラーがでます。
データ送信時に、接続が完了していないのが原因だと思いますが
どうすれば、ひとつのアクションで、接続とデータ送信ができますでしょうか?


63 :デフォルトの名無しさん:03/05/15 00:06
眠ればいい

64 :デフォルトの名無しさん:03/05/15 00:36
>Myrinet のホストアダプタには、32bit の RISC プロセッサである LANai が搭載されており、Myrinet 上での通信プロトコルを自由に実装することが可能である。
とあるページにこんな説明がありました。
複数の演算機用で計算の途中結果をやり取りをするようです。
プログラマブルのNICみたいですね。
スイッチもハブでは遅くて、Ethernet switchというのがあるとか。
OSに付属するTCPやIPなどは介しないんではないでしょうか。

私が欲しいのもズバリこれですが、機能がTCP/IP/Ether固定で安いやつないですかね。
0.7M円もします、、0.07Mならなんとか(死


65 :デフォルトの名無しさん:03/05/15 00:55
MyrinetはMyrinetスイッチ、Ether switchは普通のNIC用ですね。
Myrinetの値段も違ってました。
17〜30万ぐらいらしいです。

66 :デフォルトの名無しさん:03/05/15 01:17
>>64
なにを言ってるのかわからない。
ふつうのGbEとスイッチならビックカメラにでもいけば普通に売ってるが、
OSのTCP/IPの実装が重過ぎるのがけしからんといってたんじゃないの?
>>39じゃなかったらスマン。

67 :デフォルトの名無しさん:03/05/15 01:50
>>66
いえ、39ですよ。
OSのTCPの実装が重いのではなくて、仕様がそうなっているわけで仕方が無いと言った記憶しかありません。
私はMSは好きではありませんが、VCなんかを使っているとプログラマもとても無能とは思えないので、TCPの実装が得に駄目とは考えません。
そういう事で私が今回の試みでTCPを使うのを止めようと言った訳です。

64ではMyrinetはいわゆるネットワーク用の演算プロセッサが搭載されていると言っています。
TCPの実装が重くても、必要な演算をCPUで行わなければあまり問題は無い(コストはかなり問題)です。
恐らくMyrinetは↓のようなことが出来るデバイスです。(プログラムサイズが足りるかなどは知りませんが)
「このデータをTCPIPでIP何番に送っといてくださいね、終わったら通知下さい。」(前書いたやつ)
そのようなデバイスがありふれていないのは世の中のPCが低レイテンシの通信を必要とするような用途に使われないためでしょう。
下記はクラスタに関する資料ですが、TCPのデータサイズに対するレイテンシのグラフもあります。
www.softek.co.jp/CID/Presen/PDF/comm-lib.pdf
↑同じ悩みを持つ方々がいるようですが、独特なプロトコルを使うと相手が受け取れません_| ̄|○


68 :デフォルトの名無しさん:03/05/15 01:56
>>62
ブロッキングすれば?

69 :デフォルトの名無しさん:03/05/15 02:20
>>62
しかたがねぇな、ダメな見本としてしょぼい事を書いてやるか。
Private Sub Command1_Click()
Winsock1.Close
Winsock1.Connect "127.0.0.1", 1001
Do While Winsock1.State <> sckConnected
DoEvents
Loop
Winsock1.SendData "test"
End Sub
Private Sub Winsock1_SendComplete()
Winsock1.Close
End Sub

70 :デフォルトの名無しさん:03/05/15 05:18
>>39の人

MMORPGでも作ってるんですか?

71 :デフォルトの名無しさん:03/05/15 06:35
C/C++で日本語コードを変換する無料でメジャーなライブラリってないですか?
perlだと定番があるみたいなんですが。

調べたらIBMのICUってのだけ見つかったんですが、これって
みなさん使ってます?もっといいのがあったら教えてください。

72 :デフォルトの名無しさん:03/05/15 06:52
>>71
ググればたくさんヒットするから再調査したほうが良いと思うけど、
nkf,wkf,qkcとかCで書かれたプログラムは色々あるから
ライセンス確認してパクれば?
jcode.plに匹敵する知名度のものは知らない。

73 :スレ違いsage:03/05/15 07:34
>>71
iconv

74 :だったら答えるなよ、タコ。:03/05/15 09:16


75 :デフォルトの名無しさん:03/05/15 16:59
つーか、WinSockコントロールって接続完了したらConnectイベント来るだろ。
ちゃんと組むなら、タイマコントロール辺り使って「一定時間たってもConnect
イベント来なかったら諦める」ようにした方がいいけど。

76 :デフォルトの名無しさん:03/05/15 18:06
>>71
Unicode系にはくれぐれも気を付けろよ。
基本的に非Unicode->Unicodeってやったら、逆変換は
必ず同じライブラリを使うこと。
外から素性の知れないUnicodeがやって来たら、もう
どうしようもないけど。

77 :62:03/05/15 22:35
>>63,69
ありがとうございました。
DoEventsがポイントでした。どうもでした。

78 :デフォルトの名無しさん:03/05/15 23:25
今時DoEventかよ。

79 :62:03/05/16 06:33
>>78
どこがまずいのでしょう?

>>75
そうですね、そのあたりも気を付けたいと思います。


ところで、みなさんWinSockコントロールを使わずに
API?を直接つかってコーディングしているみたいですが、
なぜでしょうか?
VBのがWinSockコントロールのほうが、簡単だと思うのですが、、、

80 :デフォルトの名無しさん:03/05/16 07:24
>>79
まさかあのソースをそのまま採用したわけじゃあるまい?
タイムアウトもキャンセルもエラー処理もないし。
あと、DoEventsとSleepを両方つかうかな。気休めかもしれんが。

APIとWinSockコントロール云々は、違いをみればわかるのでは。

81 :デフォルトの名無しさん:03/05/16 11:09
>>70の人
鯖管は嫌いですが、MMOのサーバープログラムには興味があります、、。

UDPで14バイトを秒間20000送信で、Send側で850Mhz消費という結果が、機能を考えるとオーバーヘッド軽減も微妙です。
あと、再起動をしようがパケットを送りつけると無条件に受け取ってしまうPC君に萎えました。
しかも、WINのIPフィルタをONにしつつも、WinSock使用のソフトウエアが受け取っている場合より負荷がかかってしまうのは謎です。
NICやルーターでフィルターかませないとアタックされたら死ねますね。
うちのルーターは設定かえる再起動となるので、、、。
アタック->IPフィルタ設定->サービス停止->モツカレ(゚Д゚)




82 :デフォルトの名無しさん:03/05/16 11:28
今度はルータに負荷がかかると

83 :デフォルトの名無しさん:03/05/16 18:24
不正にACKつけるとそこらのルーターのIPフィルタは通り抜けるらしいぞ
アタック->IPフィルタ設定->サービス停止->再起動->不正パケット通過->サービス不能->モチュカレ
だな

84 :デフォルトの名無しさん:03/05/16 23:41
いや、だから個人用途の製品で欲張るなよと・・・
金とらなきゃやってられない製品になったら業務用の製品使わざるをえんだろ・・・

85 :デフォルトの名無しさん:03/05/17 12:54
個人で金掛けてもしょうがないですよね。
吉報そうな情報と言えば、去年の暮れ辺りからDOS遮断機能付きのBBルータが各メーカーから既存の価格で出てきたようです。
競争の一環でしょうけど、こういった機能が世の中のニーズ(死語?)になって発展をみれば私は恩恵を受けれそうです。
どちらにせよ、WinSockでDosアタックを考慮に入れるのは無茶ですね。

86 :デフォルトの名無しさん:03/05/17 13:49
電波のスクツかよ!

87 :デフォルトの名無しさん:03/05/20 14:41
getaddrinfo() の第1引数に空文字列(NULLポインタじゃない)を渡した時は仕様上どうなるんでしょう?
RFC2553をざっと目通しても書いて無いようでした。

識者の方教えてくだちい。

環境は Windows、Linuxでふ。
 Windowsの場合: 0リターンでローカルアドレスが第4引数で戻る。
 Linuxの場合: エラー。
と、なりますた。


88 :87:03/05/20 14:42
つづき

以下、Winで試したコード
#include <winsock2.h>
#include <ws2tcpip.h>
#include <tpipv6.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main()
{
  int ret = 0;
  struct addrinfo hints, *res = NULL;
  WSADATA data;
  WSAStartup(MAKEWORD(2, 0), &data);
  memset(&hints, 0, sizeof hints);
  hints.ai_family = AF_INET;
  hints.ai_flags = AI_PASSIVE;
  hints.ai_socktype = SOCK_STREAM;
  ret = getaddrinfo("", "ftp", &hints, &res);
  if (ret != 0) {
    printf("getaddrinfo error\n");
    printf("%s\n", gai_strerror(ret));
    printf("ret: %d\n", ret);
  }
  else {
    printf("success\n");
  }
  return 0;
}


89 :ヽ(´ー`)ノ:03/05/20 15:49
仕様も何も、非 0 が返ってくるだけでは?
手元の Linux 2.4.20 だと EAI_NONAME、FreeBSD 4.8 だと EAI_NODATA が返ってきたけど(笑)。
検証したコード。ちなみに res は NULL だった。

int main()
{
  int ret = 0;
  struct addrinfo hints, *res = NULL;

  memset(&hints, 0, sizeof(hints));

  hints.ai_family = AF_INET;
  hints.ai_flags = AI_PASSIVE;
  hints.ai_socktype = SOCK_STREAM;
  ret = getaddrinfo("", "ftp", &hints, &res);

  if (ret != 0) {
    printf("getaddrinfo error\n");
    printf("%s\n", gai_strerror(ret));
    printf("ret: %d\n", ret);

    printf("%p\n", res);
  } else {
    printf("success\n");
  }

  return 0;
}

winsock の挙動はいくら何でもおかしいだろう。
> Linuxの場合: エラー。
segmentation fault でも起こした?

90 :87:03/05/20 16:33
>>89

非0 を期待していたら、Windows 2000とWindows XP上では 0が返ってきて正常終了処理に入ってしまったのでつ。

>> Linuxの場合: エラー。
>segmentation fault でも起こした?
あ、これは非0が返ってきたってことですた。この動作は期待通りでいいでつが、Windowsがねぇ。

現在は if (ノードがNULLでない && strlen(ノード) == 0) だったら、という処理を入れてお茶を濁してまつ。(´・ω・`)

検証ありがとうございます>89


91 :ヽ(´ー`)ノ:03/05/20 16:43
>>90
なるへそ。漏れも参考になりますた > winsock2 の動作。

92 :デフォルトの名無しさん:03/05/20 18:33
どうでもいいが、strlenじゃなくて1文字目が'\0'かで判定しろよ

93 :デフォルトの名無しさん:03/05/21 08:51
>>92
if (node && !*node)


94 :デフォルトの名無しさん:03/05/21 11:26
if (node != NULL && node[0] == '\0') の方が…。

95 :90:03/05/22 00:12
>>92 strlenじゃなくて1文字目が'\0'かで判定しろよ

ヲット、そうでつね。

>94でいきまつ。



96 :デフォルトの名無しさん:03/05/22 00:18
Cプログラマは>>94より>>93を好む傾向にある。

97 :デフォルトの名無しさん:03/05/22 01:28
オレは>>94の方が好きだけどなぁ

98 :デフォルトの名無しさん:03/05/22 02:27
>>96-97
Cプログラマはタイプ数が少ないほうが好きな人が多いんじゃないかなぁ
PascalとかVerilogとかがbeginとendで複文を囲むのに対して
Cでは{と}で複文を囲む辺りなんかを見てもそう思う

99 :94:03/05/22 08:50
俺も昔は
 char *p = malloc(100);
 if (p) {
   ....;
 }

とかやってたけど、ある日、実はものすごい読みにくい事に気がついて
>>94 のスタイルにした。でも !*node は流石に無いよなぁ。

100 :93:03/05/22 11:04
>>99
読みにくいかな? 俺にはそのコードで十分、分かりやすいけど...。
ただ、気になってるのは >>93 みたいなコーディングでも、
C として正確なのかなぁ? と。
自分で自信がなかったりするもんで。

でも、確かに !*node なんて記述は普段やったことないです。
せいぜい *node == '\0' かな。


101 :デフォルトの名無しさん:03/05/22 11:53
>>98 Cプログラマはタイプ数が少ないほうが好きな人が多いんじゃないかなぁ

んなぁことない。

begin end と {} については、ありゃぁ殆ど慣れの問題だ。


102 :デフォルトの名無しさん:03/05/22 17:45
>>101
んなことない

103 :デフォルトの名無しさん:03/05/22 18:57
Cにも省略の美学みたいのないか?

104 :デフォルトの名無しさん:03/05/22 19:04
スレ違い警報&コーディングスタイル論争警報

105 :デフォルトの名無しさん:03/05/23 13:58
質問です。
Linux で socket 使ってますが、受信バッファを
クリアする関数ってないようなのですが・・・

無効なコマンドが到着したらバッファクリアしたいよー。

106 :デフォルトの名無しさん:03/05/23 14:37
recvすれば?

107 :デフォルトの名無しさん:03/05/23 15:26
なんでクリアしたいの? どうせ、次に受信した
データで上書きされるんだし。

クリアしたいなら、bzero(buf, sizeof(buf));
とかやっとけば? ゼロクリアの場合だけど。


108 :デフォルトの名無しさん:03/05/23 16:08
>>106-107
あぁ・・・
質問の仕方がマズーですね。
アプリ側のバッファじゃなくて、socket の受信バッファなんですけど・・・
受信ルーチンであるサイズ分のデータだけ読んで
正常コマンドなら残りを読むって作ってます。
んで、未知のコマンドなら socket バッファに残ってる分をクリアしたい、と。
socket バッファより大きなデータん時はそんとき考える、と・・・


109 :デフォルトの名無しさん:03/05/23 16:13
>>108
STREAMなソケットなら、クリアしたとしても
未取得のどこまでバッファに届いているかわからないので
途中がぶった切られることになるんだが。
中身を見ずに任意の途中を抜いても後続データを回復できるような手順なの?

110 :デフォルトの名無しさん:03/05/23 16:53
>>109
どもです。
はい、出来ません。
今は socket バッファより小さいんで大丈夫かと。
仕様変わったらどうしょ。

別の質問ですが、不定長データのやり取りで
でたらめなデータを受信した場合ってどうやってます?
blocking mode なんですけど・・・


111 :107:03/05/23 17:16
>>108
とりあえず、読みたい先頭数byteだけのバッファを用意して、
recv() の MSG_PEEK フラグ使えば?
それも途切れてくる可能性があるんなら、MSG_WAITALL フラグ
も一緒に使う。

んで、正常なメッセージっぽかったら受信して処理すればヨシ。
異常だったとしても、一旦読み込むしか方法は無いよ。


112 :デフォルトの名無しさん:03/05/23 17:25
>>110
>不定長データのやり取りででたらめなデータを受信した場合
識別用ヘッダ・データ長・データ・チェックサム
というデータ形式にして常時チェック

113 :デフォルトの名無しさん:03/05/23 17:47
>>111
>異常だったとしても、一旦読み込むしか方法は無いよ。
そですか。

>>112
はい、今そうしてます。
この件についてはちょっと考えすぎだったようです。

みなさんどうもでした。
このスレは親切な人達で一杯ですねー。
こんなヘタレでもレスがもらえる・・・


114 :デフォルトの名無しさん:03/05/23 17:49
>>111

MSG_PEEKは、すくなくとも WinSockの場合、酷い目に遭う可能性あり。
(特に、Win98のWinSock)
WinSockFAQにも、PEEK は危険と、載ってたんじゃなかったかな。

115 :デフォルトの名無しさん:03/05/23 18:14
>>113
スレ違いの話が横行してたからな。運が良かったと思え。

116 :デフォルトの名無しさん:03/05/24 11:12
>>110
> 不定長データのやり取りで
> でたらめなデータを受信した場合ってどうやってます?

server/client共に開発主である場合。

1. そんなことがないようにprogrammingする。(これが解決策第一候補)

相手は別の開発主である場合。(相手が糞なら↑は無理)

A. '\0'をデータ区切りとして利用する等、境界をはっきりさせることを徹底する。
B. それでもやばそうな場合は、接続を捨てることとし、
  再接続関連をprotocol仕様に含める。

ちなみに>>110はTCPがbyte streamを提供するということを理解してないようなので、
良く勉強するように。TCPをSOCK_SEQPACKETと勘違いしているようだ。

> 今は socket バッファより小さいんで大丈夫かと。

の発言とかかなり疑問。

以上SOCK_STREAM(TCP)に限った話でした。


117 :デフォルトの名無しさん:03/05/28 10:43
NLSTコマンドで
NLST -alL public_html/aaa/
などとしてフォルダ内のファイル一覧を取得しているのですが
このコマンドでフォルダのみを抽出するほうほうはありますか?
宜しくお願いします。

118 :山崎渉:03/05/28 12:27
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

119 :デフォルトの名無しさん:03/05/28 17:19
TCPで大量のデータを送信する場合、
sendで指定するサイズはヘッダ込みで
1500バイト以下に抑えろと言われたのですが
それで転送速度が上がるものなのですか?

120 :デフォルトの名無しさん:03/05/28 17:27
>>119
何 故 試 さ な い ?

121 :デフォルトの名無しさん:03/05/28 17:54
途中のフラグメントを抑えるためだろ

122 :デフォルトの名無しさん:03/05/28 20:43
>>121
関係ないと思われ。

多分、>>119 にその入れ知恵をしたヤツは、Nagle アルゴリズム
と遅延 ACK による送信遅延を起こさないように、という意図で
入れ知恵したんだろう。ところが >>119 はそのことを理解してな
いので、かなり端折った表現になってるだけだと思う。

それで転送速度が上がるんじゃなくって、送信遅延を防ぐんだ。

が、これまた、その入れ知恵したヤツがホントに >>119 に書い
てある通りのことを言ったんだとしたら、アフォだな。
ちいさいサイズずつ send() したら、モロに送信遅延しちゃうよ。
遅延させたくなけりゃあ、デカいサイズで一気に send() しろ。
下が Ethernet だとしても、1500 超えても問題なし。TCP が
1460 byte ずつ回線に流すから。遅延無しで。


123 :デフォルトの名無しさん:03/05/28 22:51
>>119
馬鹿な先輩は無視するに限る。
それだけじゃ実際のところは分からないが多分馬鹿。



124 :名無しさん@Meadow:03/05/29 01:02
>>117
NLST って、FTPのコマンドか? なら無理だと思われ。

そもそも FTP のプロトコル上 NLST の引数の解釈について明確な記述は無いので、
実は -al が期待通りに動くかどうかさえサーバ側(ftpd)の実装依存。

まあそれを踏まえたうえで、できることは -l の出力を grep '^d' するくらいじゃない?


125 :デフォルトの名無しさん:03/05/29 01:26
>>119
あるいはUDPについてだったとか。
UDP で Ethernet 前提なら、無駄なフラグメントを減らす
(でパケット喪失の確率を減らす)ように、最大1500バイトってのはありかも。


126 :デフォルトの名無しさん:03/05/29 08:19
そういう勘違いをする奴がUDPなんか使うとロクなことにならんと思う

127 :デフォルトの名無しさん:03/05/29 18:58
前にも>>126のような馬鹿なレスしてた奴いたよなw

128 :デフォルトの名無しさん:03/05/30 16:40
FTPのLISTコマンドでファイルの日時が表示されますが
ファイルによって時間だったり年だったりしているのですが
どちらかに統一できないのでしょうか?
できてば年月日時分が取得できればいいのですが

129 :デフォルトの名無しさん:03/05/30 17:01
> FTPのLISTコマンド

ファイル名以外の情報については規定が無かったらしく、
クライアント作成者は皆ハマる、と以前聞いたよ。

130 :デフォルトの名無しさん:03/05/30 17:01
と思ったら>>124も書いてるやん

131 :デフォルトの名無しさん:03/05/30 17:04
あららそうですか・・
FtpFindFirstとか使えば日時は取得できるのですが
それをやっちゃうと今度はパーミッションが取得できないんですよね・・
LISTとAPIを両方行えばいいのですがそれだとリスト取得に倍の時間がかかってしまうし・・

132 :デフォルトの名無しさん:03/05/30 17:22
>>131
何か勘違いしているようだが
相手先のサーバが情報を返さないのであれば、
APIを使っても当然取得できない

133 :デフォルトの名無しさん:03/05/30 19:07
>>132
いや勘違いしてるかもしれないが試したことを言っている。
APIで取得できてLISTコマンドとかでは>>128ってなる

134 :デフォルトの名無しさん:03/05/30 21:02
>>133
そのFtpFindFirst APIが実際にどのコマンドを発行してるかを調べるしか。
FTPってコマンドはテキストで流れるから脳

135 :デフォルトの名無しさん:03/05/30 23:34
>>132
まあ、人の言うこと聞かない奴は放置するしかないよ。

>>134
と言うか、CUI で ftp クライアント使ったことないのか ?
debug モードにすれば、送ってるコマンドとかも表示されるぞ。

136 :デフォルトの名無しさん:03/05/31 01:44
サーバによってはSIZEとかMDTMというコマンドをサポートしていて
いろいろ取得できる場合もある

137 :デフォルトの名無しさん:03/05/31 19:29
>>131
> それをやっちゃうと今度はパーミッションが取得できないんですよね・・

Authorizationなんか、システムによって仕様が違うもんな。
ftp protocolで決めようないわな。

serverがUNIX系だと仮定した時、出来るベストのことはなんでしょう、
くらいの質問に切り替えた方がいいと思われ


138 :デフォルトの名無しさん:03/06/06 11:06
UDPで受信側PCで受けの体勢を取っていない場合(受信するソフトを起動していない)
送信側からドンドンデータを送っても受信側PCには何も影響ないでしょうか?

139 :デフォルトの名無しさん:03/06/06 11:16
無駄な負荷が若干かかるくらいで、
誤動作することはないよ。

140 :デフォルトの名無しさん:03/06/06 11:19
>>138
馬鹿なシステムの場合、DoSとなる可能性あり。

141 :デフォルトの名無しさん:03/06/06 19:14
UDPってローカルIPだけで有効なんですか?

142 :デフォルトの名無しさん:03/06/06 19:31
アハァ?

143 :デフォルトの名無しさん:03/06/06 19:32
>141
んな訳ねぇべよ。それじゃDNS届かないじゃん。

144 :デフォルトの名無しさん:03/06/06 19:56
だれかJAVAでやってる香具師いる?Cが多いみたいだけど。

145 :デフォルトの名無しさん:03/06/06 19:59
TCP/IPソケットプログラミング C言語編 Java編出版記念age
これ単なるライブラリの説明だけじゃなくパフォーマンスとかを含めた
ノウハウも説明している貴重な本だよ。値段も安いし。

146 :デフォルトの名無しさん:03/06/06 20:55
>>145
UNIXネットワークプログラミング 第2版 Vol.1より良い?!


147 :デフォルトの名無しさん:03/06/06 20:58
>>145-146
スレ違い

148 :デフォルトの名無しさん:03/06/06 21:00
>>147
スレ違いと言い切ってしまうお前に乾杯。

149 :145:03/06/06 21:01
それと比べちゃいけない。って説明が悪かったか。
こっちは200ページ弱の大学生用の入門書だよ。

150 :デフォルトの名無しさん:03/06/06 21:01
>>148
http://pc2.2ch.net/test/read.cgi/tech/1051496506/

151 :デフォルトの名無しさん:03/06/06 21:04
>>150
知ってる。だから「言い切ってしまう」って書いた。

152 :デフォルトの名無しさん:03/06/06 21:07
>>147
邪魔だ

153 :デフォルトの名無しさん:03/06/06 21:08
やっぱり多重継承は必要ってことだな

154 :デフォルトの名無しさん:03/06/06 21:10
>>153
なこたーない。

155 :デフォルトの名無しさん:03/06/06 21:15
多重継承ってなに?

156 :デフォルトの名無しさん:03/06/06 21:18
>>155
ネットワーク推薦図書スレを立てろってことだよ。

157 :デフォルトの名無しさん:03/06/06 21:19
>>156
ハァ?

158 :デフォルトの名無しさん:03/06/06 22:12
nntpみたいにクロスポストの仕組みがあればいいのに

159 :デフォルトの名無しさん:03/06/06 23:39
業者がますますウザイだけ

160 :デフォルトの名無しさん:03/06/06 23:56
javaでアプレットのLAN対戦とか、できる?
socket使うのんだろうけど・・どうやるんだ?

161 :デフォルトの名無しさん:03/06/06 23:57
webブラウザで見るアプレット?

162 :デフォルトの名無しさん:03/06/07 00:52
IEでみれれば^^;

163 :デフォルトの名無しさん:03/06/07 01:08
>>160
webサーバと通信サーバを同じマシンに置けば?

164 :デフォルトの名無しさん:03/06/07 11:59
そのソースください・


165 :145:03/06/07 21:51
>>149
買ってみました、UNIXネットワークプログラミングより
薄いし、安いし、FAQとの組み合わせで結構いけるかも。
#ただ、コーディングスタイル合わなかった。

166 :デフォルトの名無しさん:03/06/08 23:58
x-deflate はどんなエンコーディングですか?
google しても、適当な解説が見当たらなかったのですが。

167 :デフォルトの名無しさん:03/06/09 01:01
VBのWinsockコントロール・UDPプロトコルで通信プログラムを作成
しているのですが、データをバイト配列に代入してから小出しにして送信
したいのです。しかし、いかんせんやり方がよく分かりません。知っている
方がいたら教えてください。(VBのスレの方でも聞いたのですが、こっち
で聞けば?と言われたのでこっちで聞いてみました)

168 :デフォルトの名無しさん:03/06/09 01:07
何がわからないのかさっぱりわからん

169 :デフォルトの名無しさん:03/06/09 01:19
>>168
説明がよくわからなかったかもしれないので端的に言うと、
データをバイト配列に代入して、それを分割してSendDataするには
どうすればよいか教えてくださいという事です。


170 :デフォルトの名無しさん:03/06/09 05:58
>>166
zlibにinfrate()がある。続きは圧縮スレで。
>>169
それVBのprogramming作法の問題じゃん。

171 :デフォルトの名無しさん:03/06/09 06:00
>>170
だからどうした? スレ違いだと言いたいのか?

172 :デフォルトの名無しさん:03/06/09 06:19
>>170
> zlibにinfrate()がある。続きは圧縮スレで。
inflate ですね。

173 :_:03/06/09 06:29
http://yomi.kakiko.com/hiroyuki/jaz_b01.html

174 :デフォルトの名無しさん:03/06/09 07:10
811 :デフォルトの名無しさん :sage :03/06/05 05:28
ちょっと質問なんですが、WinsockコントロールでTCPでは普通に送れていた
データがプロトコルをUDPにしたら、「データグラムはバッファより大きい
ため切り詰められます」と出るようになってしまいました。内容はそのままんま
なのかもしれませんが、これを解決するにはやはり小出しにして送るしか
ないのでしょうか?やはりこれがプロトコルの違いなんですか?


175 :直リン:03/06/09 07:13
http://homepage.mac.com/yuuka20/

176 :デフォルトの名無しさん:03/06/09 08:24
そのままんまなのが良くないんだろうね
言葉の意味は分からないが

177 :デフォルトの名無しさん:03/06/09 11:51
>>174
> やはりこれがプロトコルの違いなんですか?

そだね、プログラミングモデルを替えないとね。
バーチャルサーキットからデータグラムに変るわけだから。

178 :デフォルトの名無しさん:03/06/09 19:48
ネットワークの「ネ」の字も知らない初心者です。
一応、C/C++言語でグラフィック、サウンドプログラム等をしてます。
今さらながら、ネットワークプログラミングを勉強したいのですが、
最初に何から始めれば良いでしょうか。

お勧めのソースや環境や書籍等あったら教えてください。

179 :デフォルトの名無しさん:03/06/09 20:02
>>145

180 :デフォルトの名無しさん:03/06/09 20:32
>>170
> >>166
> zlibにinfrate()がある。続きは圧縮スレで。
あとで調べてみます。


181 :デフォルトの名無しさん:03/06/09 23:20
WinSock2.0プログラミング―Window Socket APIによるネットワークプログラミングのすべて
http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/ref%3Dpd%5Fsims%5Fdp%5F%5F1/249-7083274-8757158

この本買った人いますか?内容はどんな感じでしょう?
当方Windows-style API+シングルスレッドでサーバを作ったのですが
Berkeley-style API+マルチスレッドで作り直したいのですが挫折しています.

182 :デフォルトの名無しさん:03/06/09 23:26
>>181
WinSock2.0の書籍ってそれしかないから迷わず買うしか。
APIを一通り説明してある。ついでにここもあわせて読むべし
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

183 :181:03/06/09 23:30
>>182
レスありがとうございます.
一応Webは一通り調べてみたんですけど良いサンプルは
そのHPぐらいですよね.
とりあえず買ってみようかな,ちょっと高いけど...

184 :デフォルトの名無しさん:03/06/10 00:00
なるべく書籍の話題は専用スレでやってほしい。

185 :デフォルトの名無しさん:03/06/10 04:55
昨日からちょっと潔癖すぎない?関係ない話でも無いんだし…。

186 :デフォルトの名無しさん:03/06/10 07:20
あんまり話題がないんだし、
書籍の話とかでも関係があれば構わないのでは。

187 :デフォルトの名無しさん:03/06/10 07:51
一人が騒いでるだけだろ、ほっといてやれよ。

188 :デフォルトの名無しさん:03/06/10 11:16
>>185
昨日から?>>170か?

189 :魔法使い:03/06/11 00:59
ボケ防止にサーバーを作ろうと考えてます
UNIXだとデーモン、窓だとサービスね。一応マルチプラットホーム予定
一応 ソケットのソの字はわかってるつもり。
TCPのサーバ(Winsocでマルチスレッド)は作った事あるけど
今度は、メールサーバ DNS みたいなのを作りたいと思います
で 質問ですが 複数接続の時
・セキュリティーを考えてfork() あるいはexec()を行い、データのやり取り必要ならIPCするのが良いか
・スレッドを使うのが良いか

どう思いますか?

190 :デフォルトの名無しさん:03/06/11 01:00
頭使うのが嫌なら前者、パフォーマンス上げたきゃ後者。

191 :デフォルトの名無しさん:03/06/11 01:12
win32でforkやるのはしんどいと思う

192 :魔法使い:03/06/11 01:21
不慮の事故とか(一般保護エラーなど)でCrashを考えた場合
落ちる可能性の高い、クライアントとの通信部を
別プロセスにしたら親に被害が出なくて良いかな?って悩んでたのです
スレッドにすればTCPプログラムなら簡単そうですね
IPCも考えなくていいし
UDPだとパケットの識別->スレッドへ配送 とか考えないとね・・

193 :デフォルトの名無しさん:03/06/11 01:55
udpなら、多重化する必要はないとおもうけおど、、

194 :デフォルトの名無しさん:03/06/11 02:14
>>193
多重化は(必要な時は)しないまずいでしょ。
DNSのproxy serverなんかだと、domainごとに応答時間が違うから、
query/responseのprocessをoverlapして処理する必要がある。


195 :デフォルトの名無しさん:03/06/11 09:13
>>189
自分で考えずに他人に頼る時点でボケ防止にならない
諦めて徘徊でもしてろ

196 :デフォルトの名無しさん:03/06/11 09:23
>>191
つか、win32 って fork() できるんですか?
UNIX 育ちの俺は、以前仕事で WinNT 4.0 上で動く
デーモン (サービス) 書いた時に、fork() が無くて
キレそうでした。子プロセスを起こすのって、
fork/exec がセットになったような API しか無くって。

最近のWindows 事情はさっぱり知らないんですけど。


197 :デフォルトの名無しさん:03/06/11 10:59
>>196
Win32サブシステムには無いがPOSIXサブシステムには存在する。

あと、CygwinはWin32サブシステム上で色々小細工してfork()を実現
してる。(つか、実現しないとアプリが移植できないし)
かなり遅いけどね。

198 :デフォルトの名無しさん:03/06/11 12:23
まあPOSIXサブシステムではsocketが使えないという罠があるわけだが
(Interixなら使える)

199 :デフォルトの名無しさん:03/06/12 02:22
WINSOCKとかを使ったソフトでのエラー処理とかが詳しく載っている
ようなサイトをどなたか知らないでしょうか?

200 :デフォルトの名無しさん:03/06/12 02:23
msdn

201 :デフォルトの名無しさん:03/06/12 18:59
FAQみたいなのが見たいんじゃないの?
なんでもかんでもmsdnとか言うのはイクナイ!

>>199
msdn見ればイイと思うよ。

202 :デフォルトの名無しさん:03/06/13 21:17
おいおい(w

しかしマジレスすると、「エラー処理」をどうするかはアプリ/プロトコル
次第なんだから、MSDN見たってしょうがないと思うんだが。

「エラーコードはどうやって拾えばいいのか?」「エラーコードの意味
が知りたい」とかならMSDN見ろでいいけど。

203 :デフォルトの名無しさん:03/06/14 06:44
>>200が馬鹿なんですか?>>202が馬鹿なんですか?

204 :デフォルトの名無しさん:03/06/14 08:30
>>1001までで>>203が一番馬鹿。


205 :デフォルトの名無しさん:03/06/16 10:54
残念。俺が記録更新。

206 :デフォルトの名無しさん:03/06/17 17:25
そして俺が行進

207 :デフォルトの名無しさん:03/06/17 23:03
  _、_
( ,_ノ` )y━・~~~  ヽ(゚∀゚)ノ
            >>206

        _、_
≡≡≡≡( ,_ノ` )y━・)∀`)ノ
             >>206

208 :デフォルトの名無しさん:03/06/20 14:06
質問ですが、
UDPで通信を行っていてrecvfrom関数で受信しているのですが
この時に相手のIPアドレスを知りたいのですが、
どうやって取得すればいいのでしょうか?宜しくお願いします。

209 :デフォルトの名無しさん:03/06/20 14:09
マニュアル嫁

210 :デフォルトの名無しさん:03/06/20 14:11
本なんか買わなくてもAPIのマニュアルとか見れば分かるだろ
本に教えて貰わないと何もでき無いような奴は何をやっても駄目

211 :デフォルトの名無しさん:03/06/20 15:41
>>209-210
知らないならレスしないで、ウザイだけだから

212 :デフォルトの名無しさん:03/06/20 15:43
>>211
同感
以前からこのスレを荒らしているやつだから無視した方がいいよ。

213 :デフォルトの名無しさん:03/06/20 15:43
>>211
(´д`)
recvfrom使ってるのになんで分からないのかね?
recvfrom関数自体で分かるではないか。まったくマニュアルを見ていないのか?

214 :デフォルトの名無しさん:03/06/20 15:43
>>208
相手のIP知ってどうするの?

215 :デフォルトの名無しさん:03/06/20 15:45
>>211
マニュアルに載ってることを
質問すのは禁止です

216 :デフォルトの名無しさん:03/06/20 15:46
>>208=211=212
バレバレですよw

217 :デフォルトの名無しさん:03/06/20 15:53
釣りなんだろうなぁ。

218 :デフォルトの名無しさん:03/06/20 17:53
accept() と同じ方法で取得できるYO!
...って回答じゃダメ?

つーか、だったら何でコイツは recvfrom() を使おうと
思ったんだろう…。


219 :デフォルトの名無しさん:03/06/20 18:33
>>215
マニュアル買ってくれ

220 :_:03/06/20 18:51
http://homepage.mac.com/hiroyuki44/

221 :デフォルトの名無しさん:03/06/20 19:00
http://www.linux.or.jp/JM/#search
http://www.linux.or.jp/JM/html/LDP_man-pages/man2/recvfrom.2.html

222 :デフォルトの名無しさん:03/06/21 00:29
IPの詐称ってプログラムレベルでできるもの?
方法はいいのでできるかできないかだけ知りたいんだけど。

223 :デフォルトの名無しさん:03/06/21 00:32
socket apiレベルじゃできない。
やるんならドライバレベルじゃないの。

224 :デフォルトの名無しさん:03/06/21 00:38
TCPで詐称したらコネ確立できんのでは

225 :デフォルトの名無しさん:03/06/21 01:36
>>222
raw socketってのでlayer 2叩けば出来る。
>>223
raw socketはsocket APIの一部つー事でいい。

226 :デフォルトの名無しさん:03/06/21 03:12
>>224
シーケンス番号を予測できれば
一方的に何か送りつけることはできるね

227 :デフォルトの名無しさん:03/06/21 17:55
初歩的な質問ですいませんが
サーバ側でrecv()でクライアント側のメッセージを受けとるときに
クライアント側でsend()でメッセージを送った直後に同様にsend()で違うメッセージを
送ってやると、サーバ側で2つのメッセージを同時にrecv()で受け取ってしまうのですが
これを解決する最適な方法ってなんでしょうか?

現在はスリープしてやって時間差をあけて送るようにしてますがこれでいいのでしょうか?

228 :デフォルトの名無しさん:03/06/21 17:57
>>227
いいわけないだろ
TCPが分かっていない馬鹿はUDPを使え

229 :デフォルトの名無しさん:03/06/21 18:01
>>227
ワラタ。
まじれすするとだな、そういうもんなんだよもとから。
メッセージの中身に区切りを入れろ.

230 :デフォルトの名無しさん:03/06/21 18:03
クソだよね

231 :デフォルトの名無しさん:03/06/21 18:05
デバッグ中はrecv(sock, buf, 1, 0)で受けても破綻なく動くように作っとけ。

232 :デフォルトの名無しさん:03/06/21 21:43
>>228
初心者にUDPすすめていいことはなにもn(ry


233 :デフォルトの名無しさん:03/06/22 11:06
>>228,232
お前ら、粘着かよ(w


234 :デフォルトの名無しさん:03/06/22 12:20
質問に答えたら粘着呼ばわりかよやれやれ
質問者の気に入るように嘘をつけとでもいうのか?

235 :デフォルトの名無しさん:03/06/22 12:24
        .┌┐
        / /
      ./ / i
      | ( ゚Д゚) <そんなバナナ!
      |(ノi  |)
      |  i  i
      \_ヽ_,ゝ
        U" U

236 :デフォルトの名無しさん:03/06/22 12:49
IDがACK

237 :デフォルトの名無しさん:03/06/22 14:14
ID!?

238 :デフォルトの名無しさん:03/06/22 23:36
>>227
固定長/可変長/不定長でぐぐると良いです

239 :デフォルトの名無しさん:03/06/22 23:56
たぶんUDPの動きを期待してるんでしょ?
UDPにするのがいいと思われ

初心者には、UDPの方が理解しやすいのかもしれないなぁ
こう、パケットが飛んでいくイメージ、というか

240 :デフォルトの名無しさん:03/06/22 23:58
そうじゃないだろ。
ストリームを理解すればいいだけの話。

241 :デフォルトの名無しさん:03/06/23 00:00
処理速度と仕様要件によるけど、1通信ごとに切断するのはどうか。

242 :デフォルトの名無しさん:03/06/23 00:16
?

243 :デフォルトの名無しさん:03/06/23 01:03
>>239
もしかして釣り?
単に初心者なのか?

244 :デフォルトの名無しさん:03/06/23 01:52
>>241
効率悪すぎだろ。それこそUDPにしたほうが。
あ、でも「サーバ側で逆順に受け取ってしまうのですが、
これを解決するにはsleepで(ry」とか言い出す予感。
やっぱ自称初心者に付ける薬はないな

245 :デフォルトの名無しさん:03/06/23 02:33
そもそも、あの質問に対してUDPを勧める奴こそ初心者ではないか
と思うがどうか。問題の一つには244で気づいたようだが、問題は
それだけではないから、ふつう227レベルの質問に対しては、最初
からUDPなんて答は除外してかかるもんだ。それとも228も239も
241も全て釣りか?

まともなレスは229,240あたりか。
でも、区切りを入れるよりも、メッセージ長を示すヘッダを頭に
つける方が定石だと思うがどうよ? >>229

246 :デフォルトの名無しさん:03/06/23 05:17
>>245
そんなんプロトコルによるだろ。
もしPOP3がメッセージ長方式だったらtelnetでつないでPOP3おしゃべり
できないし。(まぁやってやれなくはないが、お手軽さは無くなる)

ただ、区切り文字方式でバイナリ通す場合はTELNETのIACエスケープ
のような事しなくちゃいけなくなるから、面倒くささという意味ではどっちも
どっちだけどナー

247 :デフォルトの名無しさん:03/06/23 06:14
HTTP/1.0はまさに>>241なわけだし釣りとまで言い切るのはどうかと。

248 :デフォルトの名無しさん:03/06/23 07:51
しつこいよ

249 :デフォルトの名無しさん:03/06/23 09:17
手軽さを求める理由が判らない
そんなにデバッグ環境が貧弱なのか?

250 :デフォルトの名無しさん:03/06/23 09:29
POP3のRFC作った人に言ってください
ネットワークプログラミングでどの環境でも
デバッグ環境が充実してると思うほうがどうかと

251 :デフォルトの名無しさん:03/06/23 10:03
>>249
> 手軽さを求める理由が判らない

The Internet protocol suitesのアプリケーション層って手軽指向だよ。
例えばOSIと比べてご覧よ。

まあ、本論は、パケット長方式でも境界区切り方式でも、
状況に合わせて好きな方を選べばいいと思うが。


252 :デフォルトの名無しさん:03/06/23 10:27
パケット長という言い方は誤解を招きそう
メッセージ長でしょ?

253 :デフォルトの名無しさん:03/06/23 11:20
ハンドシェイクしれば?

254 :デフォルトの名無しさん:03/06/23 11:27
>>253=馬鹿

255 :デフォルトの名無しさん:03/06/23 11:54
なして?

256 :デフォルトの名無しさん:03/06/23 12:13
>>255
友好関係でも築こうとしているのか?

257 :デフォルトの名無しさん:03/06/23 12:15
なんでこのスレ厨房が常駐してるんだ?
最近ネットワークの宿題が流行ってるのか?

258 :デフォルトの名無しさん:03/06/23 13:10
今月のCマガの記事どうよ?

259 :デフォルトの名無しさん:03/06/23 13:15
あーわかった(´,_ゝ`)
>>254>>256か、こいつ用語どころか、仕組みを理解してねえよゲラゲラ


260 :デフォルトの名無しさん:03/06/23 13:20
もともとTCPの話題から発展してきたのに、
今更>>253がスレを読まずに発言することが、馬鹿ではなくてなんだというのだ?

261 :デフォルトの名無しさん:03/06/23 13:32
C++で送受信バッファを管理するクラスってどっかにない?
ついでにプレゼン層の実装用の便利クラスも。

262 :デフォルトの名無しさん:03/06/23 13:34
>>261
ある

263 :デフォルトの名無しさん:03/06/23 13:37
>>260
お前のように答えられないで煽るだけの馬鹿は邪魔dから消えてくれ頼むから
いつも邪魔してるのお前だろ?
ここはお前のような低脳がくるとこじゃねえよ。

264 :デフォルトの名無しさん:03/06/23 13:44
>>263
>>261

265 :デフォルトの名無しさん:03/06/23 14:11
>>263
スレを読まずに突然頓珍漢なことを書くのもどうかと思うが
落ち着いてスレの流れを把握してから書き込むように

266 :デフォルトの名無しさん:03/06/23 14:17
| 旦  コソッ
|∧∧
|゜・ω・゜)
|o○o  .
|―u'   
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


|   またーりしようよ。おにぎと茶でもどうぞ。
|∧∧
|゜・ω・゜)
|o o  .
|―u'   旦○
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


|
|   サッ
|
| ミ
|     旦○
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

267 :デフォルトの名無しさん:03/06/23 14:17
|       ○ミ
|     旦
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


|       ○
|     旦
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


268 :デフォルトの名無しさん:03/06/23 14:18
|     ○   ゴ
|     旦   ゴ
|     ||||   ゴ
|         ゴ
|         ゴ
|
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

|     ||||   ゴ
|         ゴ
|
|
|
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


269 :デフォルトの名無しさん:03/06/23 14:18
|
Σ∧∧
|゜・ω・゜) ナクナッテル‥湯ノミマデ‥
|o o  .
|―u'   
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


270 :デフォルトの名無しさん:03/06/23 14:20
>>263
煽るだけでなく答えることもできる上級者さんなら早く>>261に答えろ。

271 :デフォルトの名無しさん:03/06/23 14:34
>>265
やっぱわかってねえかこいつ・・

272 :デフォルトの名無しさん:03/06/23 15:23
>>271
恥の上塗りみっともない

273 :245:03/06/23 23:07
>>246
POP3 や SMTP みたいに最初から区切りとして使えるもの(改行)が
あるなら、それを使えばいいけど、区切りがないデータに対して、
後から区切りを加えるのは、ちょっと面倒だと思うなあ。

ヘッダにメッセージ長を入れるのは、全然面倒じゃないよ。
メッセージ長って、システムコールの引数でどうせ必要だから、
既に分かっている筈なので、直接send/recvする代わりに、
send_with_size/recv_with_sizeみたいな関数を作って呼ぶだけ。

まあ、セパレータを入れることに反対しているわけじゃないので、
そう受け取れたならスマソ。


274 :デフォルトの名無しさん:03/06/24 00:14
>>273
send_with_terminator/recv_until_terminator でいいと思う。

メモリ管理はメッセージ長方式の方がチョト楽だけどな。
メッセージを丸ごとdataとして扱う場合に限りだけど。

275 :デフォルトの名無しさん:03/06/24 01:24
>>245
そこまでTCPを勧めるなら、根拠を書けよ
UDPはダメだという思い込みで、思考停止してるだけじゃないか?

一応先に書いておくが、>>244のように順序が変ったり、ロストする
ことがありうる、なんてことは誰でも知ってる。それでも、使いやすいのなら
UDPもいいのでは、ということだ。

つーか >>245 こそ釣りか

276 :デフォルトの名無しさん:03/06/24 01:38
テキストベースのプロトコルなら、改行をセパレータにするのが自然な気がする。
それにしてもなんで、CR LF の2バイトがセパレータのプロトコルが
多いんだろ。(HTTPとか TELNET とか) 
1バイトの方が作りやすいのに・・

277 :デフォルトの名無しさん:03/06/24 02:25
>>275
> なんてことは誰でも知ってる。

と思い込むのはあなたの勝手だが、
今ここでは>>227が知っているかどうかが重要。
また過去スレを読めば「誰でも知っている」なんて
妄想以外の何物でもないことが分かる。あなたは馬鹿か?

>>276
Internetでは、ISO IRV 646その他の制御文字の定義に合わせて、CF + LFが標準。


278 :デフォルトの名無しさん:03/06/24 02:30
こういうのは元質問者が話に参加しないので、回答者が質問者の環境を各々想像しながら
回答するので、話が噛み合わなくて回答者同士で煽り合いになるのが常道だな。
どのスレでも。

279 :デフォルトの名無しさん:03/06/24 04:11
TCPでメッセージ境界を実装するのと、
UDPでメッセージ順序の保存と再送と(メッセージのサイズによっては)
メッセージ分割と再アセンブリを実装するのとで、
どちらが簡単かなんて自明じゃろう。
想像するまでもない。

280 :デフォルトの名無しさん:03/06/24 07:26
適材適所、必要ないプロトコルなら滅んでいる
利点を生かす用途で使い分ければいい

281 :デフォルトの名無しさん:03/06/24 08:28
いまさらテキストベースのプロトコルにこだわる理由が判らない。

282 :デフォルトの名無しさん:03/06/24 09:28
>>281
いちいちそんなことにつっかかる、
お前の思考もわからない。

誰も「こだわって」はいないと思うんだが。


283 :デフォルトの名無しさん:03/06/24 11:48
制御方法によるな
テキストならターミネートコードで終了が認識できるが
バイナリだとバイト数を付加する必要あるからな
バイナリにしたらサイズが小さくなるから速度優先ならアレ


284 :デフォルトの名無しさん:03/06/24 14:12
FTPのように切れたら終了という手はある
制御用と転送用でコネクションを分けてもいいし

285 :デフォルトの名無しさん:03/06/24 14:57
>>284

終了方法の話とは、直接関係ないのだけれど、一般論としては、
ftp protocol は、新しい protocol を実装するときのお手本には
しない方が良い、と思う。
たとえば、

・複数ポート(特に不特定のポート)を使う。(FWのフィルタ設定が面倒)
・新しく開いたポート番号を相手に教える。(NAT対応で問題を起こす)
・サーバからクライアントに接続する。(ftpの場合passiveがあるけれど)

というのは、やらないで済むなら、やらない方がよいわけで。
FTPの場合は、歴史があるから、FW や NAT では特別扱いで、
いろいろ専用対応してくれているけれど。

286 :デフォルトの名無しさん:03/06/24 15:51
>>285
同感。FTP をマネるのはやめた方がいい。
新しく listen したポートに本来の通信相手じゃないヤツが
コネクション張ってきたらややこしいしね。FTP のプロトコル
自体はそれをやらせるために設計されたので、ああいう、
ヤヤコシイ作りになってるんだけど。


287 :デフォルトの名無しさん:03/06/24 20:07
オンラインゲームを作りたいんですが
どうすれヴぁいでつか?

288 :デフォルトの名無しさん:03/06/24 20:33
>>287
まずゲームをつくる

オンライン化する

(゚∀゚) ウマー

289 :デフォルトの名無しさん:03/06/24 21:13
>>287
テキストベースのプロトコルを使わない。
tcp一本でイケるとこまでがんがる。

290 :デフォルトの名無しさん:03/06/24 22:33
> テキストベースのプロトコルを使わない。
何の関係があるんだ? >>281か? 必死すぎ

291 :デフォルトの名無しさん:03/06/24 23:14
まさか、いまどきデバッグ環境が貧弱だなんてありえないんじゃない?

292 :デフォルトの名無しさん:03/06/24 23:59
バイナリ転送は、バイトオーダに気をつけるべし。

最近プレゼンテーション層相当はHTTP系、ASN.1系が多いね。

293 :デフォルトの名無しさん:03/06/25 00:23
おいおい。HTTP はバイナリも通るよ。

294 :292:03/06/25 00:42
知ってますが何か…

295 :デフォルトの名無しさん:03/06/25 00:50
ASN.1ってバイナリエンコードの方法だっけ?

296 :デフォルトの名無しさん:03/06/25 01:03
>>294

ふむ、じゃあ XML のことを言ってるわけじゃなかったのか。

だとすると、それって本当にプレゼンテーション層?
アプリケーション層としてのHTTPを、ありとあらゆるアプリ
ケーションに使うって意味じゃなくって?

297 :デフォルトの名無しさん:03/06/25 05:50
>>291
自分の使ってる環境がすべてだと思ってる人は
ネットワークプログラミングに向いてないよ

298 :デフォルトの名無しさん:03/06/25 07:44
じゃ、ビックエンディアンで

299 :デフォルトの名無しさん:03/06/25 07:57
>>297
ふむ、具体的にはどんな環境だと問題になりますか?

300 :非297:03/06/25 08:12
>>299
どんな環境でも問題にならないようにするのが、一(いち)プログラマーの
義務と思ってるんだが…間違っている?

「どんな」ていうのは、少し偏見であるが…

301 :デフォルトの名無しさん:03/06/25 10:44
なんか、殺伐としてきたなぁ。
ここは吉野家か?

一人だか二人だか変なのが紛れ込んでるだけみたいなんだけど。


302 :デフォルトの名無しさん:03/06/25 12:20
>>289
>テキストベースのプロトコルを使わない。
>tcp一本でイケるとこまでがんがる。
って意味わかんないのは俺だけ?

テキストベースプロトコル 対 TCP

なの?わけわかめなんだけど。


303 :デフォルトの名無しさん:03/06/25 12:36
わけ割れめ

304 :デフォルトの名無しさん:03/06/25 13:13
>>302
お前だけじゃないから、安心しろ。>>289 がアフォなだけ
だから相手にするな。


305 :デフォルトの名無しさん:03/06/25 22:39
>>302
二行は別のことを言ってるぞ。
テキストベースの弊害は既知だからいいとして、
tcp一本というのはどういう理由なんだろう

306 :デフォルトの名無しさん:03/06/25 22:47
>>305
テキストベースの弊害は既知なの?

307 :デフォルトの名無しさん:03/06/25 23:02
>>306
オモチャレベルのプログラムしか作ったことがないアマチュアには
既知ではないかもしれん。

308 :デフォルトの名無しさん:03/06/25 23:07
驚愕の事実!
インターネットの大部分は玩具レベルのプログラムで運営されている

309 :デフォルトの名無しさん:03/06/25 23:07
>>307
うう、べつにテキストベースだってエンコードすれば何でも通せるし
(「テキストベース」という言葉で示しているのは通信路を通すのを許す
値範囲が0x0aとか0x20〜0x7fとかいう範囲だという程度だよね?)
何が弊害なのか分からん・・

310 :デフォルトの名無しさん:03/06/25 23:29
>>309
「メッセージの長さが終端マークが来るまで判らないプロトコル」
のことだと思う。行末までとか、行頭に"."が来るまで、とか。
この手の仕様がbuffer overrunを生みやすいのは既知だと思うがどうか。

でも、長さの指定はテキストでもできるんだから、
テキストベースの弊害という表現はポイント外してるな。

>>308
互換性・相互運用性の名の下に黎明期のプロトコルが残ってるだけでは?

311 :キリスト者:03/06/26 02:05
>>310
アンチ・テキストハケーン


312 :デフォルトの名無しさん:03/06/26 03:12
>>311
310は「改行区切り方式だとバッファ溢れの危険性が伴いやすい」
という事を言ってるだけで、別にテキストそのものを否定してる訳
ではないと思うが。

313 :デフォルトの名無しさん:03/06/26 06:36
一行の最長文字数に関する規約をつければいいだけの話しですな。

314 :デフォルトの名無しさん:03/06/26 09:17
バイナリでもバッファオーバフローは起こる
テクスト/バイナリに限らず、きちんと許容サイズをチェックするのは必須

315 :デフォルトの名無しさん:03/06/26 22:05
>>313
実際メールには一行の長さの制限がありますな
もちろん実装はちゃんと制限をチェックしないとぜんぜん意味ないが

316 :デフォルトの名無しさん:03/06/27 11:21
>>310
それはテキストベースだから、という問題じゃないと思うぞ。
テキストベースだろうが、データ長を先に通知することは可能だし、
バイナリデータを通すプロトコルだったとしても、特定のコード
を終端と見なす方式も存在しえるわけで。

というわけで、テキストベースの弊害を説明してください。
おながいします。


317 :デフォルトの名無しさん:03/06/27 12:11
>>316
・バイナリに比べて通信量が増える。
・解析されやすい

318 :デフォルトの名無しさん:03/06/27 12:26
>>317
まじですか

319 :デフォルトの名無しさん:03/06/27 12:31
> ・解析されやすい
それは通信路の暗号化で解決すべき問題だと思うが

320 :デフォルトの名無しさん:03/06/27 12:53
> ・バイナリに比べて通信量が増える。
それは通信路の圧縮で解決すべき問題だと思うが

321 :デフォルトの名無しさん:03/06/27 13:46
暗号化/圧縮したら普通はバイナリになるような…

322 :デフォルトの名無しさん:03/06/27 16:06
暗号化/圧縮はここでテキストとかバイナリとか問題にしてる
層より上位で透過的にやるってことだよ
sshを通したtelnetをバイナリプロトコルとは言わないだろ

323 :デフォルトの名無しさん:03/06/27 18:42
言うけど

324 :デフォルトの名無しさん:03/06/27 20:03
( ゚Д゚) ウソー

325 :デフォルトの名無しさん:03/06/27 20:17
かなりの亀レスですいません。
何人かの方々、回答していただきありがとうございました。

>>225の方に個人的にご相談したいことがあるのですが、
まだいらっしゃいますか?

326 :デフォルトの名無しさん:03/06/27 20:18
結局方法を知りたくなったのかw

327 :222:03/06/27 20:19
>>325は元222です。

328 :>>225:03/06/27 20:46
いるけどさ、ここはプログラム技術版ってことを忘れないでね。
それから他の人も答えられるよ。Cracking program書く人は放置、が不文律だけど。

329 :デフォルトの名無しさん:03/06/27 21:01
>>316

310は
>でも、長さの指定はテキストでもできるんだから、
>テキストベースの弊害という表現はポイント外してるな。

と言ってるが、国語力が不足しているのか?

330 :222:03/06/27 22:12
>>222です。
場違いは甚だしいのを承知で書かせていただきます。
仕事柄よくi-modeサイトを閲覧するのですが、
DoCoMoのIP以外だと閲覧できないようになっているサイトがあり、
パケット代も馬鹿にならず、仕事に支障をきたしております。
User-Agentであれば自力でも詐称できるのですが、IPアドレスとなると
お手上げの状態です。

そこで、一時的にDoCoMoのIPになりきってi-modeサイトを閲覧できるような
ツールが欲しいのです。
閲覧するサイトは決まっていますので、Windowsのコマンドラインから
必要な引数を渡して、レスポンスを受け取るだけの簡単なものでいいのですが、
そのようなツールを製作するのが可能な方がいらっしゃったら、
メールでご連絡いただけないでしょうか?
もちろん謝礼はご用意するつもりです。

>>328
ご忠告ありがとうございます。
レスを汚してすいませんでした。
書き込みはこれで最後にします。

tadokoro226@hotmail.com


331 :デフォルトの名無しさん:03/06/27 22:24
そんなこと言い出したらIPもTCPもバイナリのヘッダを持つんだから
その上で動くプロトコルは全部バイナリだわな。
RFC3252を使えば話は別だが(w

332 :デフォルトの名無しさん:03/06/27 22:32
>>330
sourceIP詐称は簡単にできるけど、その返事は自分に帰ってこないぞ?

333 :デフォルトの名無しさん:03/06/27 22:35
現在主流の外部ルーティングプロトコルは、ソースIPが経路に一致しないとパケットを捨てる
よって送信も出来ない

334 :デフォルトの名無しさん:03/06/28 00:17
>外部ルーティングプロトコル

AS同士の通信、BGPとかのこと?

>ソースIPが経路に一致しないとパケットを捨てる

しらなんだ...

335 :デフォルトの名無しさん:03/06/28 00:30
エッジルータで捨ててると思ってた・・・

336 :デフォルトの名無しさん:03/06/28 01:03
できるところもまだまだたくさんあるよ。
tracerouteに-gつけて確かめてみ。

337 :デフォルトの名無しさん:03/06/28 01:11
(´-`).。oO(…ICMPなのに・・・)

338 :デフォルトの名無しさん:03/06/28 01:48
>>333
少くともIPレイヤはそんなことしてないだろ。
行きと帰りで経路違うだけで通信できなくなっちまう。

339 :デフォルトの名無しさん:03/06/28 05:42
>>338
何で? 行きと帰りはまったく関係ないと思うが?

340 :>>225:03/06/28 08:32
>>330
> そこで、一時的にDoCoMoのIPになりきってi-modeサイトを閲覧できるような
> ツールが欲しいのです。

不可能です。
通信料じゃなくてサービス料なのでちゃんと払いましょう。

スレ違い失礼。

341 :デフォルトの名無しさん:03/06/28 12:29
送信元偽ってどうやってサーバから情報を送ってもらうんだろう・・・

342 :デフォルトの名無しさん:03/06/28 12:35
>>341
"Man in the Middle" attackなら容易でしょ?
一般的には不可能だけど。

343 :名無しさん@お腹いっぱい。:03/06/28 16:46
socket( AF_INET, SOCK_DGRAM, 0 );
IPv4でデータグラム型。つまりUDP。外部と通信可。

socket( AF_INET, SOCK_STREAM, 0 );
IPv4でストリーム型。つまりTCP。外部と通信可。

socket( AF_LOCAL, SOCK_DGRAM, 0 );
Unixドメインプロトコルでデータグラム型。名称なし。同一マシンのみ。

socket( AF_LOCAL, SOCK_STREAM, 0 );
Unixドメインプロトコルでストリーム型。名称なし。同一マシンのみ。

ただ、45のように127.0.0.1をローカルマシンのIPアドレスとして
TCPやUDPで通信することもできるヨ。

344 :デフォルトの名無しさん:03/06/28 17:41
いきなりなんだ?

345 :デフォルトの名無しさん:03/06/28 18:18
今日はそんなに暑くなかったんだがな

346 :デフォルトの名無しさん:03/06/28 18:38
世界中・・・いや日本中どこでも気温が同じだと思っているのか。

347 :デフォルトの名無しさん:03/06/28 18:53
え、同じじゃないの!?

348 :デフォルトの名無しさん:03/06/28 19:55
>>346
ネタにマジ返しされても・・・

349 :デフォルトの名無しさん:03/06/28 20:13
>>347
安心してください。同じですよ。

350 :デフォルトの名無しさん:03/06/28 20:58
話題のSOCK_RAWくらい入れといて欲しいもんだな。

351 :デフォルトの名無しさん:03/06/29 00:45
raw sockはMSにより使用を禁じられているわけだが。

352 :デフォルトの名無しさん:03/06/29 02:49
>>351
ソースきぼんぬ。

icmp.dllは将来サポートされなくなる(から使っちゃ駄目よ)というのは
知ってたが、WinSock2のRAWソケットも駄目ってのは初耳だな。

(というか、icmp.dllを使わせたくないからWinSock2でRAWソケットを
正式サポートしたはずなんだが)

「WinSock2 RAW ソケット」でぐぐってみたが、サンプルは腐るほど
出てくるが、禁止されているという話は全然無いんだけど。

353 :デフォルトの名無しさん:03/06/29 10:56
icmp.dllを廃止されると、一般ユーザーでpingがとばせなくなって困るんだが・・・

354 :デフォルトの名無しさん:03/06/29 12:41
>>353
むなわきゃーない。
iphlpapi.dllにさっさと移行しなさい。

355 :デフォルトの名無しさん:03/06/29 12:53
age

356 :デフォルトの名無しさん:03/06/29 19:01
>>352

351 ではないけど、MS の KB の Q195445 (英語) で、
「Admin 権限がないとダメよ」みたいな事が書かれている。
351 はそれを「禁止」と捉えているのではないかな?

ping を飛ばすサンプルらしきものをやはり MS KB の
Q185726 (英語) に発見。詳しく読んでいないけど、
ActiveX 作って ping を飛ばすものらしい。

>>354

スレ違いな質問かもしれないけど、iphlpapi.dll って IPv6
のサポートあるの?アドレスの格納に DWORD を使って
いて「なんだかなぁ」って思った記憶があるんだけど。

357 :デフォルトの名無しさん:03/06/29 20:52
>>356
IPv6用にIcmp6CreateFileって6の名前のついたAPIが新規追加されてる。
XP以降だが。

358 :デフォルトの名無しさん:03/06/30 10:58
そーゆーことをしてるからAPIの数がどんどん肥大化するんだろうに

359 :デフォルトの名無しさん:03/06/30 11:10
>>358
APIの数が少なかったらドキュメントの類が売れないからだろう。

360 :デフォルトの名無しさん:03/06/30 11:26
何とかExとか言う名前で、ぼこぼこ増えてるな

361 :デフォルトの名無しさん:03/06/30 17:59
俺は専用APIが出来る方が便利だと思うがね。
使わない人は見なくても使わなくていいんだし、不要になったら廃棄すりゃいいんだし。
汎用化してるとそれこそドキュメントがぼこぼこ肥大化していくでしょーが。

362 :デフォルトの名無しさん:03/06/30 18:08
> 不要になったら廃棄すりゃいいんだし。
それができてりゃ文句を言わんがね
実際には後方互換性の問題から膨れてくいっぽうじゃん。
潰しの効かない特殊化されすぎたAPIを毎度毎度覚えてくのはたくさん

363 :デフォルトの名無しさん:03/06/30 18:27
突然ですみませんが
send時のblockって何が原因で起こるんですか?


364 :デフォルトの名無しさん:03/06/30 18:38
送信バッファに空きがないとき

365 :デフォルトの名無しさん:03/06/30 18:38
相手がrecv()してくれないとか

366 :デフォルトの名無しさん:03/06/30 19:20
>>362
おいおい、そのスパンってどれくらいよ。
数ヶ月単位なら俺も勘弁してもらいたいが3年から5年とかなら一向にかまわんよ。
それもできないなら単なる甘えにきこえるよ。

ICMP.dllは実際にまだ消えてないし、次のOSで消えたとしても現状のXPまでは使えてるんだから
何を問題にしているんだ。
業務系だったら対象OSまである程度固定化できるし、固定してから作るだろ。

367 :デフォルトの名無しさん:03/06/30 21:17
win sockで質問が あります
今ファイル送受信 プログラムを作っているのですが、送受信を同時にすると止まってしまいます

・まずは コネクト確立。ソケットを作成
・自分が送信
・相手もこっちに送信

とやると、sendから -1しか返ってこなくなってしまいます
固まる理由はわかっていて、ファイル送信途中 でとあるヘッダ(8バイト)を渡すために無理やり無限ループしているところヘッダが破損しては
困るので8バイト渡すまでsend部分をループさせてるのです(Sleep(2)あり)

ここからは素人考え
受信に一杯一杯だとsendは失敗する
だから8バイトとはいえ無限ループしているところのsendで失敗を繰り返してしまい固まる
何故なら無限ループ中はrecvしていないから

この推測は当たっているでしょうか?
recvに手一杯だとsendは失敗してしまうのでしょうか?
また、これの解決方法は?(ソケット2つつくる…とか?)無限ループやめろはごもっともですが・・・

368 :デフォルトの名無しさん:03/06/30 21:29
>>367
勉強に使ってるテキスト・情報源は何?

369 :デフォルトの名無しさん:03/06/30 21:46
すれっど

370 :デフォルトの名無しさん:03/06/30 22:17
>>367
>自分が送信
>相手もこっちに送信

受信してないの?バッファが一杯になるとそれ以上送信できないよ?そういうわけではなくて?
send でループする間も recv を回してバッファを空けてやるといいのでわ。

>固まる理由はわかっていて、ファイル送信途中 でとあるヘッダ(8バイト)を渡すために無理やり無限ループしているところヘッダが破損しては

ヘッダが破損て何。TCPでは一応データ破損しないはずでは。
勝手に仮定したけど、TCPだよねぇ?何かと勘違いしてる?ん?

371 :デフォルトの名無しさん:03/06/30 23:17
>>366
まあ、すっきりしたら、

> 業務系だったら対象OSまである程度固定化できるし、固定してから作るだろ。

ドロドロした世界でゴミ拾いして銭稼いでいる人は困るわな。

372 :デフォルトの名無しさん:03/07/01 07:16
つーかMicrosoftだってサポートのコストがどんどん増えて大変だと思うんだが
だからLonghornで大ナタをふるうとか言い出したんでしょ(どうせできっこないが)

373 :デフォルトの名無しさん:03/07/01 11:10
>>367
激しく何かを勘違いしていると思われ。
「ヘッダが破損」ってのが意味不明。

とりあえず send() が -1 return してるんなら、
エラーコードを見なきゃ。


374 :デフォルトの名無しさん:03/07/01 15:41
WSAEWOULDBLOCK辺りと見た。

375 :デフォルトの名無しさん:03/07/01 22:08
>>374
じゃあ>>367はOSをversion upすべきだな(w

376 :374:03/07/02 08:13
>>375
ん?意味分からんのだが…

要するにrecv()してないからバッファがいっぱい→にも関わらずsend()
しまくるので「これ以上送れねーよヽ(`Д´)ノ」とWSAEWOULDBLOCKが
出てるのでは?という事なのだが。(だからOSは関係無い)

ひょっとして漏れ釣られてる?

377 :デフォルトの名無しさん:03/07/02 09:36
recvしてないのは相手なの? 自分なの?

378 :デフォルトの名無しさん:03/07/02 13:10
>・自分が送信
>・相手もこっちに送信

つー辺りからして、両方共recv()してないとか。
ま、なんにせよ>367は説明が全然駄目すぎてどういう状況なのか
サパーリ分からん。

379 :デフォルトの名無しさん:03/07/03 23:39
IEで、ftp://user:pass@ftpサーバのhost名/
でftpサーバにアクセスするとき、
プロトコルは何を使ってるんでしょうか?
会社のマシンの場合でも、HTTP用のproxyしか設定してないはずなのに、
ftpサーバとつながるのが不思議でしょうがないです。(ダウンロードのみでも)
何か特殊な事をしてるんでしょうか?
検索しても情報がないです。(どういうアクセス手段かもわからないし)
あわよくば自分のプログラムのftpルーチンにも導入したいのですが・・・

380 :デフォルトの名無しさん:03/07/03 23:59
>>379
Browserがftp protocolを喋って、
あたかもHTMLであるかのように表示してるんです。

ftpのhttp proxyも同じ事やってます。(こっちはprotocolもftp→http変換してる)

381 :デフォルトの名無しさん:03/07/04 00:14
>>380
でも、ftpポートは見えてない筈なんですが。
FFFTPやrootftpみたいなFTPクライアントじゃ同じ事できないですよね。
結局これは何というプロトコルなんでしょうか?

382 :デフォルトの名無しさん:03/07/04 00:20
ネットワークと言っていいものか怪しいのですが、
PC間をモデムで直接つなげて、シリアル通信でデータのやりとりってできるものでしょうか?

383 :デフォルトの名無しさん:03/07/04 00:22
>>380
もしかして、ブラウザがHTTPじゃなくて、始めからftpプロトコルで通信してるということですか?
でもポートが1つで済む意味がよくわからない。
ftpの場合はサーバから開くポート要求されるはずなんだけど・・・。

384 :デフォルトの名無しさん:03/07/04 00:23
httpでつないで、
GET ftp://ftp.example.jp/dir/file.txt HTTP/1.1
とかやると、ファイルが落ちてくるようなProxyサーバは存在する。
client-proxy間はhttp. proxy->server間はftp。

385 :デフォルトの名無しさん:03/07/04 00:46
>>382
モデムじゃなくシリアル(クロス結線)なら余裕
そうじゃなくてモデムじゃないと嫌だい!!ってことなら回線シミュレータが必要
結構高額

386 :デフォルトの名無しさん:03/07/04 01:01
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
ネットで稼ぐならこれ。完全無料!!
リンクスタッフになれば小遣い稼ぎができます!!(左下に詳しい説明があります)
[報酬について]
クリック報酬・・・1クリックされる度に10円の報酬
バナー紹介料・・・リンクスタッフ登録の度に1000円の報酬
キャンペーン・・・今なら登録するだけで1000円プレゼント
間接報酬・・・紹介者が得た報酬を何割か加算いたします
ボーナス・・・優秀サイトには、報酬に応じてボーナス有り

単純に考えて1日100人クリックしたとすると、100人×10円×30日=30000円(一ヶ月)
そこらへんの掲示板に貼り付けていけば100クリックなんてスグです。
その他、自分の貼り付けた広告から誰かがスタッフになると1000円もらえるので
1日5人スタッフを紹介できたとして1000×5×30=150000円
30000+15000=180000!!間接報酬などもありますのでどんなに悪くても一ヶ月に10万円以上は稼げます!!
http://www.santa.ac/~comtec/linkstaff/cgi/click.cgi?id=3007        
ぜひ一度覗いて見てはいかがでしょうか?
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

387 :デフォルトの名無しさん:03/07/04 01:06
<input type>

とかかれたファイルをIEでひらいてみれ。


388 :デフォルトの名無しさん:03/07/04 01:08
>>385
まぁモデムを電話線直結しても、片方でatd、もう片方でataしちまえば
繋がっちゃうけどな。

389 :デフォルトの名無しさん:03/07/04 01:32

マイクロソフトと一緒でデータいっぱいだと動かなくなるワナ



390 :デフォルトの名無しさん:03/07/04 03:32
あれ?電話線直結だと、何ボルトかくっつけないとだめじゃなかった?

391 :デフォルトの名無しさん:03/07/04 03:54
>>390 ほんとはダメだけど大抵つながっちゃう。

392 :デフォルトの名無しさん:03/07/04 06:25
昔よくPCをシリアルクロス直結してKermitでファイル送りましたな。


393 :デフォルトの名無しさん:03/07/04 09:26
うむ、時々データが壊れるからチェックサムを入れて、
自分で再送処理なんかを書かなければならなかったので面倒だった

394 :デフォルトの名無しさん:03/07/04 11:05
いまはシリアル接続でもTCP/IPをのせれるんじゃなかったっけ?

395 :デフォルトの名無しさん:03/07/04 15:44
いや昔からslipとかpppとかあるけどな。

396 :デフォルトの名無しさん:03/07/04 16:24
MS-DOSではプロトコルスタックが大きすぎて
使われてなかっただけだな

397 :デフォルトの名無しさん:03/07/04 16:51
代わりにインターリンクがあったな。
クロスでつないで interlnk.exe と intersvr.exe

そういやKA9Qもあったな

398 :デフォルトの名無しさん:03/07/04 18:01
>>387
死んじゃった

399 :382:03/07/04 20:42
レスくれた方ありがとうございました。
状況としまして、事務所と工場の現場でのデータのやりとりをしようと
思いまして。

直線距離で50mくらいあるので、無線ランで中継器おいてと思ったら今は使っていない
電話の線が残っていたので、その両端にモデムをと考えました。
無線ランを使った方が良さそうですね。




400 :デフォルトの名無しさん:03/07/04 20:56
>>399
最初から書け。このバカチンが。

401 :デフォルトの名無しさん:03/07/04 22:55
>>400
荒らすな

402 :デフォルトの名無しさん:03/07/05 00:24
50mなら電話線に沿って100baseT這わせたら?
あれ100mまでじゃなかったっけ?

403 :デフォルトの名無しさん:03/07/05 00:54
UNIX/WinのTCPで、送信データを相手が正常に受信したことを判断する方法ってある?

ブロッキングソケット時は、send()の戻り値で判断?
ノンブロッキングソケット時は、送信バッファで判断?


404 :デフォルトの名無しさん:03/07/05 01:01
相手が相応の応答を返したら正常と判断する

405 :デフォルトの名無しさん:03/07/05 01:09
生ソケットを作ってACKを確認

406 :デフォルトの名無しさん:03/07/05 01:17
TCPなら保証されるんじゃないの?

407 :デフォルトの名無しさん:03/07/05 01:22
>>403
無理。
TCPレベルでは、データが化けない&順序が入れかわらないことを
保証してくれるだけで、相手が受信したかどうかまではわからない。
相手プログラムに返事を返してもらうようにして、それを確認するのが普通。


>>405
たとえACKを受けとったとしても、相手のTCPバッファに格納されただけで、
相手プログラムが受けとったとは限らない。

408 :デフォルトの名無しさん:03/07/05 03:08
>>404>>407に一票

409 :デフォルトの名無しさん:03/07/05 08:14
>>407
> TCPレベルでは、データが化けない&順序が入れかわらないことを
> 保証してくれるだけで、相手が受信したかどうかまではわからない。

(TCP layerのpeer entityまでの)到着も保証してるって。
正常にFIN処理が行なわれた時点で、すっかり判明する。

> たとえACKを受けとったとしても、相手のTCPバッファに格納されただけで、
> 相手プログラムが受けとったとは限らない。

もちろんこれは事実だけど。
Application layerのことまでTCPは責任持たないから。
TCPを利用する上のlayerの責任。

410 :デフォルトの名無しさん:03/07/05 13:06
>>409
403は「TCPを使った場合に、(アプリケーションにとって)、相手の受信確認はできますか?」
といってるわけで、TCPレイヤでの送達保証の話はちょっと違う気が。

たぶん、「最終的には FIN処理で分かる」とかいわれても、困ってしまうんじゃないかな?
実用的には、403にとって、407の対処が現実的だと思う。

411 :>>409:03/07/05 14:09
>>410
それはもちろんその通り。
ただ「TCPが」到着保証しないようにも読めてしまうので誤解がないように補足したまで。


412 :デフォルトの名無しさん:03/07/06 12:13
> 相手が相応の応答を返したら正常と判断する
しかないんじゃあ、UDPでも同じジャン。


413 :デフォルトの名無しさん:03/07/06 12:20
TCPは順序保証しかしないっしょ

414 :デフォルトの名無しさん:03/07/06 16:55
>相手プログラムに返事を返してもらうようにして、それを確認するのが普通。
相手プログラムが返事を返したかどうかはどうやって知るのでしょう?

415 :デフォルトの名無しさん:03/07/06 17:05
>>414
何が言いたいんだろう。
プログラムが返事が受信できたときでは?

相手が返事を受信したかどうかを確認するには、とかだと
無限ピンポン狙いかとも思うが・・

416 :デフォルトの名無しさん:03/07/06 18:27
>>414
返却期日を設ければいいんですよ。
1分いないに返事よこさないと未受信とみなす、とか。

417 :デフォルトの名無しさん:03/07/06 23:42
1分1秒(期限切れ)にお返事が来た時の事も考慮しておきましょう。

418 :デフォルトの名無しさん:03/07/06 23:53
いわゆるタイムアウトの処理でいいのでは。

419 :デフォルトの名無しさん:03/07/07 09:00
>>412
UDP だと順序がバラバラになる可能性があるでしょ?
それだけじゃなく、相手側アプリケーションが受信時 (recvfrom())
に指定したバッファが、実際に到着したデータより小さかった場合、
残りの分は破棄されるような実装が多いぞ。たしか XPG4 対応だと、
そういう振舞いじゃなかったかなぁ。次の recvfrom() で残りのデータ
が拾えてしまう実装もあるけど、ここいら辺は実装依存。
少なくとも XPG4 モードだと XPG4 に合わせる必要がある。

送達確認の有無だけで UDP と TCP の違いを論じるのは浅はかでつ。
このスレは「ネットワークプログラミング」スレなので、アプリケー
ションレベルでの動作も考慮しないと。

つーわけで、>>407 に同意。


420 :デフォルトの名無しさん:03/07/08 05:38
>>413
んなことはない。

421 :デフォルトの名無しさん:03/07/08 08:33
>>413
それでただしい。

422 :デフォルトの名無しさん:03/07/08 09:31
>>421
おいおい、嘘言うなよ。RFC793読んだことある?
CLOSE-WAIT stateって何のためにあるんだよ?
欠けも重複も許さずに最後はハンドシェイクして終わるんだぜ?


423 :デフォルトの名無しさん:03/07/08 17:11
> 欠けも重複も許さずに
順序保証に含まれる

> 最後はハンドシェイクして終わるんだぜ?
ソケットライブラリでアプリ作るレベルではfinを受け取ったかどうかなんて
分からん

424 :デフォルトの名無しさん:03/07/08 17:24
やれやれ・・・・

425 :デフォルトの名無しさん:03/07/08 17:56
>>423
FIN を受け取ったかどうかわからんのなら、
どうやって、コネクションの終了を判断すると考えて
ます?

>>423 は実際にソケットプログラミングやったことない
のかな? 順序保証の認識もおかしいし。それに、どうも、
TCP はその程度のことしかやらないと思ってるみたいだし。
>>424 の「やれやれ...」って言葉にものすごく同意。


426 :デフォルトの名無しさん:03/07/08 22:23
> どうやって、コネクションの終了を判断すると考えて
> ます?

誰が判断する話?主語が抜けてる。

427 :デフォルトの名無しさん:03/07/09 09:22
>>426
アプリケーションが。


428 :デフォルトの名無しさん:03/07/09 17:35
アプリケーションがコネクションの終了を判断するのにFINを使うの?

429 :デフォルトの名無しさん:03/07/09 23:44
>>428
もちろん、その通り。

ってゆうか、FIN を知っているのに、アプリケーションのレベルで、
FIN を受け取ったかの判断をどうやってやるかを知らないってのは、
あまりに駄目すぎだろう。

430 :デフォルトの名無しさん:03/07/10 03:03
Cマガに載ってたな

431 :デフォルトの名無しさん:03/07/10 06:41
>>413
TCPはcongestion controlもcheck sum testもやってないのかよ!?
どこの星のTCPだよ。

432 :デフォルトの名無しさん:03/07/10 06:42
エラー処理もロクにしないで「ソケットライブラリでアプリ作るレベル」の>>423でした。

433 :デフォルトの名無しさん:03/07/10 08:17
>>429
> もちろん、その通り。

ソケットのいろんな実装を知らない子だったか・・・
どうりで話が通じないわけだ

434 :デフォルトの名無しさん:03/07/10 12:31
>>432
FIN 受信は「エラー処理」じゃないけどな。
多分、>>423 が自作した「ソケットライブラリ」だと、コネクションの
終了を識別できないんだろうよ。


435 :デフォルトの名無しさん:03/07/10 14:15
FINぐらい受けたらわかる。

436 :デフォルトの名無しさん:03/07/10 15:26
ということは正常に切断された場合と、
NATテーブルなどがクリアされて異常切断された場合が
見分けられることになるけど、方法が思いつかない

437 :デフォルトの名無しさん:03/07/10 15:38
>>436
エラー処理をちゃんとやれよ。

TCPのレベルで到着保証がないと言うバカは流石にいなくなったか…


438 :デフォルトの名無しさん:03/07/10 15:51
エラー処理って、コネクションが失われたという判定は出来るけど、
FINを受け取って切断されたかどうかはどうやって調べるの?
別に判別できなくても困りはしないけど、
話の流れだと判定方法があるらしいので気になったんだけど

439 :デフォルトの名無しさん:03/07/10 18:01
>>438
> 別に判別できなくても困りはしないけど、

幸せなヤツだ...。

先に FIN を送出した側に TIME_WAIT が残るから、
サーバ側アプリケーションは、相手からの FIN 受信
を検出してから、ソケットを close() するのが一般的
じゃないの?


440 :デフォルトの名無しさん:03/07/10 18:52
異常切断との判別が出来ないと言っているんだけど、
何故必死に話題をそらそうとしているの?

441 :429:03/07/10 20:12
>>436,438,440

そういう場合としては、RST を受け取った場合とタイムアウトの場合があるが、
どちらもUNIX 系なら、ECONNRESET および ETIMEDOUT で分かる。
winsock の場合 ECONNRESET/ETIMEDOUT の他に、WSAECONNRESET/ESAETIMEDOUT
も別名として定義されているので、そちらを使っても良い。

>>433

なるほど、そういう意味だったか。失礼した。
で、その駄目駄目な実装ってどれよ? 実名キボン。
組み込み系ならありがちだが、もっとマトモな実装に乗り換えた方がいいん
じゃないの?


442 :デフォルトの名無しさん:03/07/10 21:31
方法を知らないだけのヴァカが逆切れしてるだけだと
完全に証明されました(w

443 :デフォルトの名無しさん:03/07/11 00:19
TCPのサービス仕様を中途半端にしか知らないので、
エラーが起きなかった時に何が達成されるか分からないんですねえ。

444 :デフォルトの名無しさん:03/07/11 00:26
socket関係って標準化されてるんだっけ?
TCPの挙動が必ずsocketに反映されるという仮定は不安があるな。

445 :デフォルトの名無しさん:03/07/11 00:31
readで要求バッファサイズ未満でも、後が続く場合があるんだよね。
まあ所詮通信制御だから当然なんだろうけど、
ストリームとして見た場合はキモイね。

446 :デフォルトの名無しさん:03/07/11 01:16
「ストリームとしては」というのが、何を意味しているかが
良く分からないが、「UNIXにおけるストリームとして」は、
バッファサイズ未満で後に続く場合があるのは、全くもって
普通というか、当たり前で、全然キモくない。
例えば、UNIX誕生当時からあるttyストリームも、まったく
同じ挙動を示すからね。


447 :デフォルトの名無しさん:03/07/11 01:19
>>444
ちゃんとソケット使う環境に応じたマニュアル読めよ。

> TCPの挙動が必ずsocketに反映されるという仮定は不安があるな。

誰がそんな大ざっぱなこと言ってんだよ。

>>445

ハゲワラタ
オコチャマかよ



448 :デフォルトの名無しさん:03/07/11 01:28
>>446
つーか、「ストリーム」だったら、
後続があるのか、いつ後続が来るか全く分からないから、
指定サイズ以下でもread/recv等が戻ってくるのは当たり前だよ。

バッファ一杯になるまで待ってたら、ブロッキングしちゃうよ。
相手がなかなか送らない場合とかにね。

→"ping MaM\r\n"(MaMは可変長メッセージね)
←"pong MaM\r\n"

これだけのプロトコルでも、1024byteのバッファ渡して埋まるまで待ってたら、
はなからブロッキングしてしまう(w

449 :デフォルトの名無しさん:03/07/11 01:58
>>448
>>446はおそらくJavaの人。
ストリーム=ブロッキングです。

450 :デフォルトの名無しさん:03/07/11 02:04
>>444
確かに、TCPが直に見える実装って知らんな。
finが分かると主張されてもねえ。

451 :デフォルトの名無しさん:03/07/11 02:26
>>450
お前もういいから寝ろ。アラシにしてもつまらん。


452 :デフォルトの名無しさん:03/07/11 02:45
>>407が間違っているの?それとも>>409が間違っているの?

453 :デフォルトの名無しさん:03/07/11 03:01
>>452
socket FAQを読みましょう

454 :デフォルトの名無しさん:03/07/11 03:45
>>452

407は、相手==相手のアプリケーション として答えていて、
409は、相手==相手のトランスポート層(==ふつうは相手のマシン
のカーネル) として答えているので、それぞれの視点では、
どちらとも正しい。
まあ、でも、403のような質問に関しては、404+407の方が
実用的な回答だろう。


455 :デフォルトの名無しさん:03/07/11 04:05
>>454
視点の違いですか。なるほど。
ありがとうございました。

456 :デフォルトの名無しさん:03/07/11 08:18
アプリケーションとしては、実用上TCPは順序保証しかしていない
(ようにみえる)ということですか?

457 :デフォルトの名無しさん:03/07/11 08:53
>>456
お前もういいから寝ろ。アラシにしてもつまらん。

458 :デフォルトの名無しさん:03/07/11 09:27
スレの方向がだんだん「猿でもわかる!TCP/IP入門!」みたいになってきたな
仕組みがわからなきゃプログラムどころじゃないわけで。
>>1-6を読んで見るとか、本買って勉強するとか。

参考に3年以上生きてる名スレを紹介してみる

これは読んどけ!ネットワーク必読書
http://pc.2ch.net/test/read.cgi/network/954649325/

459 :デフォルトの名無しさん:03/07/11 10:56
>>444
RFC はないけど、UNIX ブランド取るには X/Open のテスト
(SPEC1170) をパスしなければなりません。そういう意味で
標準はあります。関数の引数とかだけじゃなくて、細かい
動作もある程度規定されてます。

>>450
TPI (Transport Provider Interface) って知ってる?
普通のプログラマは意識せんかもしれんが...。
>>450 は TLI (XTI) の存在も知らんのだろうな。

>>456
フロー制御だってやってるだろう。それはアプリケーション
からもわかることだぞ。


460 :デフォルトの名無しさん:03/07/11 12:22
おまいらちゃんとlayerを決めてから話せよ。

461 :459:03/07/11 12:41
>>460
アプリケーションレイヤでの話でしょう。
TLI は TPI をある程度意識するよね?
ソケットは意識しないけど。

まあ、イマドキ TLI なんか使わないけど、
一つの例ということで。


462 :デフォルトの名無しさん:03/07/11 14:52
>>461
ネタ振る奴の事だろ
答える側が勝手に決めてどうするよ

463 :デフォルトの名無しさん:03/07/11 16:01
(shutdownじゃなく)closeを使っちゃいけないケースってどんなとき?

464 :デフォルトの名無しさん:03/07/11 18:15
そんなのあるの?

465 :デフォルトの名無しさん:03/07/11 18:37
例えば、複数のプロセスでソケット fd を共有していた
場合で、確実に FIN を送りたければ shutdown(SHUT_WR)
を呼ぶ必要がありますね。

ソケットを close() しても、他のプロセス側がまだ close()
してなければ、リファレンスカウンタが 0 にならないので、
FIN が流れない。こういう場合に shutdown() は使えます。

が、特殊ケースだと思う。


466 :デフォルトの名無しさん:03/07/11 19:26
>>465
複数プロセスでソケットのfdって共有できるの?
スレッドだったらわかるんだけど。
アホな質問だったらスンマそ

467 :デフォルトの名無しさん:03/07/11 19:42
アホな質問でスンマコ

468 :デフォルトの名無しさん:03/07/11 22:56
>>466
例えばforkしたら親と子で同じfdが共有されるぞ
WindowsならWSADuplicateSocketとか

469 :デフォルトの名無しさん:03/07/11 22:58
よーするにlisten, accept用はclose
通信用はshutodown

470 :デフォルトの名無しさん:03/07/11 22:58
>>465
単一プロセスでも、half open が必要な場合には、SHUT_WR が要る。

471 :デフォルトの名無しさん:03/07/11 23:56
結論が見えないんだけど・・・

472 :デフォルトの名無しさん:03/07/11 23:56
>>456
レイヤをそれに限るならば、正しい。

473 :デフォルトの名無しさん:03/07/12 00:03
そうかなあ。俺は TCP が「順序保証しかしない」なんて
言いたがる奴は、単なるアホにしか思えないんだが。


474 :デフォルトの名無しさん:03/07/12 00:18
理由を説明できない人は同じアホにしか思われないと思われ。

475 :デフォルトの名無しさん:03/07/12 00:19
>>468
なるほど、forkか。
最近、forkで子プロ作るよりも、スレッド使うほうが多いので。。。

みんな、結論って何を求めてるんだろう。
どのレイヤから見てるかってだけで、
基本的に、みんないっしょのこと言ってる気がするんだが。。

476 :デフォルトの名無しさん:03/07/12 00:27
>>474
俺のこと?
実際には、TCPは順序保証しかしないわけじゃなく、
フロー制御、輻輳回避など、他にもいろいろやっているから。
で、これらに関して、アプリケーションから介入する必要が
あることもあるから。例えば、TCP_NODELAY や、SO_RCVBUF
の設定とかね。

477 :デフォルトの名無しさん:03/07/12 02:33
ここってJavaもありですかね?Cが多いけど。。
とりあえず、通信できるか見てみようと
public String conection(String fName)
{
Socket sock=null;
InputStreamReader irStr=null;
OutputStream osStr=null;
String stReturn=new String();

try { // サーバー接続用ソケットと入出力ストリーム作成

sock=new Socket(Addr,80);

irStr=new InputStreamReader(sock.getInputStream());
osStr=sock.getOutputStream();

} catch(Exception e) {
return "Error!";
}
return "Conect";
}
こんなのを組んでみたんですが、全くつながりません。
色々やってみて、すでにウェブにアップされてた完成品のソースとかも
コピーしてみてやってみたりしたんですが、全てつながりません。。
原因わかりますか??

478 :デフォルトの名無しさん:03/07/12 02:58
手塚治はディズニーのパクリ


479 :デフォルトの名無しさん:03/07/12 05:48

Internetをはさんだ、Client/server型のSystemを作ろうと思ってます。
Serverから見た同一IPからくる、ルータ下の複数台マシンの特定は、
送信ポートで判断するのが良いのでしょうか?


私の理解では、
マルチNATを持っているルータは
パソコン1 192.168.0.2:1300>ルータ>165.62.21.30:1500
パソコン2 192.168.0.3:1300>ルータ>165.62.21.30:1501

と、ルータが自動で送信ポートを被らないようにしてくれるので、
サーバ側は送信ポートを見ればルータ下のマシンを特定が可能・・。
と考えているのですが、この考え方で設計しても問題無いのでしょうか?

また、一般的に動的NAT、マルチNATと言った場合、
TCPの機能を指すと思うのですが、UDPも含まれているのでしょうか?

TCPの方は閉めるまで状態を維持してくれそうなのですが、
UDPは時間で勝手に閉じてしまうような・・。



480 :デフォルトの名無しさん:03/07/12 06:01
独自クライアントなら、自分のIPをメッセージに埋め込んでおけばいいやん。
IP, RouterIPで区別できるでしょう。

481 :デフォルトの名無しさん:03/07/12 07:08
>>479
激しくNATの実装に依存するのでやめたほうがいい。
TCPでも、一定時間データが流れていなければ、NAT変換テーブルを消してしまう
ルータもたくさんある。

>>480みたいにするか、cookieみたいのを使うかだな。

482 :デフォルトの名無しさん:03/07/12 09:04
480のやり方だと、NATが多段にかんでいて、クライアントのIPが
全く同じになる場合にうまくいかんから、やめた方がいい。
ISP内のネットワーク全体がプライベート・アドレス空間になって
いて、各ユーザーのところと、ISPのところで、2段にNATがかむこと
があるから。

そもそもIPアドレスを埋め込むようなやり方は、アプリケーション
をプロトコル独立にするという基本原則に反するしな。IPv6 対応
するのに、アプリケーションの書き直しが必要になるというのも
嫌だろ。

だから、cookieを発行するようなやり方の方がお勧め。


483 :デフォルトの名無しさん:03/07/12 09:30
どっちにしろ、v6対応にするには、アプリケーションの書き直しは要るだろ。

484 :デフォルトの名無しさん:03/07/12 11:19
>>483
アプリケーションレイヤーのソフトウェアは getaddrinfo を使えば書き直しは必要ないと思う。


485 :デフォルトの名無しさん:03/07/12 11:20
IPアドレスを入力するUIは書き直しが必要にならんか?

486 :デフォルトの名無しさん:03/07/12 13:13
ホスト名の入力を求める程度のシンプルな UI なら書き直さなくても
getaddrinfo で十分だろ。もちろん、書き直しが必要になるようなUI
もありうるが、普通はそこまで作り込む必要もないんじゃないかな。


487 :デフォルトの名無しさん:03/07/12 14:51
>>486
うははははは、



LOGIC>>>>>>>>>>>>UI

今、
UI>>>>>>>>>>>>>>>>>>>>>>>>>>>>>LOGIC


昔>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>今

488 :デフォルトの名無しさん:03/07/12 16:52
UDPで直接DNSとしゃべりたいんですが
Ethrealみても
Transation IDとか
Queries->Nameの部分の先頭のバイトの書き方がいまいちわかりません
DNSのUDPでのクライアントの投げかけを解説してる資料ってないですか?


489 :デフォルトの名無しさん:03/07/12 16:54
>>488
RFC見た〜?

490 :デフォルトの名無しさん:03/07/12 16:57
>>489
すんませんRFCの何番でしょうか

491 :デフォルトの名無しさん:03/07/12 17:05
>>490
そんぐらい自分で探せるようじゃないと芋づるで出てくる問題に対処できんよ。
とりあえず RFC1035(STD13)。
googleで
rfc1035 日本語
と打てば日本語訳も見つかる。

492 :デフォルトの名無しさん:03/07/12 19:04
「〜をしゃべる」という表現は虫酸が走るな。

493 :デフォルトの名無しさん:03/07/12 19:59
>>492
何が言いたい?別に何とも思わないが。

494 :デフォルトの名無しさん:03/07/12 21:43
>>487
アプリケーションのレベルで、IPアドレス入力専用の
UIを持っているソフトって、そんなにあったっけか。
コントロール・パネルのIPアドレス設定とかは専用UI
だけど、たとえばInternet Explorerのproxyホスト名
設定UIみたいなのなら、getaddrinfoで書けるよな?


495 :デフォルトの名無しさん:03/07/12 22:19
>484
それは、「はじめから、v6対応で作る」というのと
どうちがうんだ?

496 :デフォルトの名無しさん:03/07/12 22:25
引っかかるとしたら入力チェック処理じゃない?

497 :デフォルトの名無しさん:03/07/12 22:40
>>496
入力チェックどうするの?
throw new IllegalArgumentException
投げるBeanにするか

UIで完全にチェックしてからBeanにセットするか

498 :デフォルトの名無しさん:03/07/12 23:16
量の問題じゃないような・・・

V6移行で忘れ去られてる問題の一つやね。

499 :デフォルトの名無しさん:03/07/12 23:50
>>495
v6 対応で作るのと、protocol 独立に作る というのの違いかな。
後者の方が、より望ましい。

実は200年後には超光速通信が発明されて、銀河間通信が可能に
なり、v6アドレス空間セマスギとか言ってるかもしれんしな。(ぉ


500 :デフォルトの名無しさん:03/07/13 01:14
そんな時代までUNIXやWindows使ってるんでしょうか

501 :デフォルトの名無しさん:03/07/13 04:22
>>500
TCP/IPは使われてそうだからコワイ(w

502 :デフォルトの名無しさん:03/07/13 07:31
>>479
> この考え方で設計しても問題無いのでしょうか?

問題ない。
TCP接続は<送受双方のIPアドレス、ポート番号>という四つ組みで識別される。

> UDPは時間で勝手に閉じてしまうような・・。

これはNAT環境依存。
TCPは上に書いた理由から必ず固定。

503 :デフォルトの名無しさん:03/07/13 09:01
>>502

> 問題ない。

俺も、問題ないような気もするんだが、その場合、そもそも
クライアント側のIPアドレスやポート番号など意識する必要ないよな。
IPアドレスもポート番号も気にせず、単純に別のコネクションは、
たとえ同一ホストから来ていても、別のホストであると解釈すれば
いいだけだから。

このスレのこれまでの回答は、同一クライアントから複数のコネク
ションが来ることもありえて、その場合、そういった複数のコネク
ションが同一ホストからであるということをサーバー側で識別する
必要がある(そのために例えばcookieを発行する)という前提で
書かれていると思う。

479の本当の意図はどちらなんだろう?
同一クライアントからの複数のコネクションを識別する必要がある?
ない?


504 :デフォルトの名無しさん:03/07/13 13:10
同一クライアントの定義にも依存しそうな予感

505 :デフォルトの名無しさん:03/07/13 14:22
説明不足でした。
もう少し付け足すと、ネットゲームを設計中です。
以下のような状況、理想を前提として、設計中です。

1、1kbyte/sec程度は常にやり取りがある
2、4〜5時間は繋ぎっぱなし
3、接続時に認証を行う
4、ユーザは、ルータの設定を行わないでも遊べる(静的NATは使わない)
5、ルータ下の同一IPからの複数の接続に対応させる。
6、古いルータにも対応させる(動的NATを利用)
7、1台1クライアント
8、可能な限りデータはスマートにする(1パケット毎にクライアント情報は入れない)

皆さんのおっしゃるcookieに相当するのは、3ですよね。
私が気にしていた一番の問題は、UDP下での、認証後のルータの挙動でした。
そもそも、8の前提から無駄データは入れたくない、
認証後はポート番号で特定しようとおもった、
しかし一度Portと認証でクライアントを特定しても、
発信ポートがいきなり変わったりしないかが心配でした。

ただ、さらに調べたのですが、
根本的にUDPを使用すると、偽証やら負荷Attackやらされやすいのに対し
(有効なデータかどうかはサーバで判断)、
TCPの接続要求Rushは、FireWallレベルでHateListに入れたりできるみたいなので、
負荷対策のためにもTcpに絞ろうと今は思っております。
>502-503
さんきゅー、安心して設計出来ます。



506 :デフォルトの名無しさん:03/07/13 14:27
データ内容に応じて両方使うとかいう選択肢はないのか・・・

507 :デフォルトの名無しさん:03/07/13 14:31
>>503
たぶん>>479は、UDPの場合について知りたい、
ポート番号が変ると困っちゃうの、というだけじゃないかな?

cookieは、

> 同一クライアントから複数のコネクションが来ることもありえて、

にも、ポート番号の変化にも対応できるから、cookieがいいと思うが。
プログラム技術版らしい解決方法だし。



508 :>>507:03/07/13 14:33
うっ! 被った上に、間違った推測…

509 :479:03/07/13 15:06
>たぶん>>479は、UDPの場合について知りたい、
>ポート番号が変ると困っちゃうの、というだけじゃないかな?

いや、正解に限りなく近い。w

>506
一応、server >Client に関してはUDPを使用しても安心かなとは思ってるんですが、
管理や汎用性を調べるのが大変そうなので、少しTcpに絞ってやってみようと思ってます。


510 :デフォルトの名無しさん:03/07/14 04:05
URL/URI の用語(ニュアンス?)の違いはどこで詳しく解説されていますか?

511 :デフォルトの名無しさん:03/07/14 05:57
w3.org?

512 :デフォルトの名無しさん:03/07/14 06:02
>>510
Googleで"URIとは"という単語で検索するとみつかる。かも。

513 :デフォルトの名無しさん:03/07/14 06:08
IT関連に限らず用語は「〜とは」で検索するとたいがい見つかるね

514 :デフォルトの名無しさん:03/07/14 11:01
>>510
RFC1737 Functional Requirements for Uniform Resource Names
RFC1738 Uniform Resource Locators (URL).
RFC2396 Uniform Resource Identifiers (URI): Generic Syntax
RFC3305 Report from the Joint W3C/IETF URI Planning Interest Group:
Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names
(URNs): Clarifications and Recommendations.

疑問点があれば、それぞれの参考資料も読むこと。

515 :デフォルトの名無しさん:03/07/14 13:06
>>513
漏れは他にも「○○ 用語」とかでぐぐってる。すると用語集などが引っかかる。

516 :デフォルトの名無しさん:03/07/14 17:01
>>511-514
>>514
RFC の番号まで教えてくださって、ありがとうございます。

517 :デフォルトの名無しさん:03/07/14 18:19
質問なんですが。

HTTP/1.1でGET投げてもHEAD投げても全く同じレスポンスが返ってくるのですが
rfc2616ではHEAD投げるとサーバーのレスポンスにメッセージボディを含まないとありますよね?

全く同じモノが返るのはおいらのプログラムがヘボなんでしょうか?
それとも同じモノが返って正解なんでしょうか?
そもそもメッセージボディって?

教えてエロイ人

518 :517:03/07/14 18:38
sageちゃったんでage・・・ヽ(`Д´)ノ

519 :デフォルトの名無しさん:03/07/14 18:45
具体的な request & response を書け。

520 :517:03/07/14 19:00
"www.yahoo.co.jp"と"/"に対して"GET"


/*戻り
HTTP/1.1 200 OK
Date: Mon, 14 Jul 2003 09:55:22 GMT
P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Cache-Control: private
Pragma: no-cache
Connection: close
Content-Type: text/html;charset=euc-jp
(略)

で、HEADを投げても同じだったという事なんですが。

521 :517:03/07/14 19:19
520の書き方ミスったんで質問撤回しときます

522 :デフォルトの名無しさん:03/07/14 21:10
yahooの鯖は行儀悪い。以上。

523 :デフォルトの名無しさん:03/07/14 21:49
何がミス?
よくわからんが、ちゃんとヘッダのみ返ってきたぞ。

524 :デフォルトの名無しさん:03/07/14 22:33
そういえば、なんでyahooって文字化けまくるの?
ブラウザではそんなことないのに。

525 :524:03/07/14 22:36
なんか馬鹿丸出しの質問しちゃった気がする…

526 :デフォルトの名無しさん:03/07/14 22:58
>>525
>>524は分かっているようだが判らない香具師の為に
「EUCだから」

527 :デフォルトの名無しさん:03/07/14 23:27
>>523
俺も試したがヤフーはダメだった
2chはヘッダだけ返した
馬鹿だからサーバー側の事はあんまわからん:・゜・(ノД‘)・゜・。

528 :デフォルトの名無しさん:03/07/14 23:41
>>517
connection: keep-alive だったらボディが返ってくるとマズイけど(次のレスポンスの開始がわからんくなる)、close だったらヘッダ後に何が返って来ようと大した問題にはならんのでは?と思った。間違えてたらスマソ。
行儀の悪い相手に寛容でありましょう、とかRFCに書いてあった気がする。うろ覚え。

529 :デフォルトの名無しさん:03/07/14 23:51
>>528
connection: keep-aliveの場合はRFCには定義はなく、
HTTP/1.1ではkeep-aliveで起きる問題を回避するために
persistent connectionとして別に定義されてるんだったような。

で、HTTP/1.1ではMUST NOT return a message-bodyなのに
結局www.yahoo.co.jpはHEADでbody返してるみたいだなあ。

530 :デフォルトの名無しさん:03/07/15 00:36
>>514に先駆けて、
http://www.w3.org/Addressing/
の図を見れば、URN, URL, URIの関係は一目瞭然。

URIが一番大きなカテゴリです。

531 :デフォルトの名無しさん:03/07/15 00:59
2ch.netlに【HEAD /2ch.html HTTP/1.0\nUser-Agent: test】とかするとHTTP/1.1 200 OK(略)
でも【HEAD /2ch.html HTTP/1.1\nUser-Agent: test】にするとHTTP/1.1 400 Bad Request

これも謎っす
HTTP/1.1にしてGETだのHEADだのしても400返すのはなんで?
2ちゃんだとブラウザとかでもHTTP/1.1を使用するのを推奨してるけど。

どうやら俺は基本がわかってない予感

532 :デフォルトの名無しさん:03/07/15 01:01
HTTP 1.1 では Host の指定が必須

533 :531:03/07/15 01:08
>>532
了解っす
勉強やり直してきます

534 :山崎 渉:03/07/15 09:36

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

535 :デフォルトの名無しさん:03/07/15 15:18
TELNETで操作する機器があるのですが、
各種開発ツール(VC++6.0,VB6.0,C++Builder6.0など)
より使用できるtelnetのコンポーネントやdll、クラスなど
の製品orフリーソフトなどをご存じないでしょうか?
ご教授、よろしくお願いいたします。


536 :デフォルトの名無しさん:03/07/15 17:28
>>535
wsock32.dllでいいの?


537 :デフォルトの名無しさん:03/07/16 22:22
>>535
BCBならIndyを使っとけ

538 :デフォルトの名無しさん:03/07/16 22:55
telnetなら意外と簡単だヨー
カラーvt100とかマジ対応考えなけりゃね
loginしてコマンド打ったりするぐらいならRFC2、3日眺めたら作れるよ
得体の知れない変なコンポーネントに頼る必要ない
だれかtelnetのソースきぼんぬ

539 :ネタばらし:03/07/16 22:57
>>538はtelnetは簡単だよといって誰かに作らせ
telnetのソースをパクろうとしている

540 :デフォルトの名無しさん:03/07/16 22:58
↑無粋って言葉知ってる?

541 :デフォルトの名無しさん:03/07/16 22:58
>>538
2,3日でつくれると嘯きながらソースきぼんぬかよ。

542 :デフォルトの名無しさん:03/07/16 23:02
和の心というのがわからないかなあ
二律背反の主張こそが日本文化の極みだヨ

543 :デフォルトの名無しさん:03/07/16 23:13
基本はIAC

544 :デフォルトの名無しさん:03/07/16 23:16
Integer And Character

545 :479:03/07/17 08:43

sageって言葉知ってる?


546 :デフォルトの名無しさん:03/07/17 09:11
>>545
なんだこいつ?

547 :デフォルトの名無しさん:03/07/17 11:38
誤爆じゃないの

548 :479:03/07/17 18:58
誤爆というか誤板でした、、ごめん。


549 :デフォルトの名無しさん:03/07/19 04:39

sageって言葉知ってる?

550 :デフォルトの名無しさん:03/07/20 00:22
セージ(Sage)[別名:薬用サルビア]
相性のよい素材

原産地:地中海沿岸
科 名:シソ科(多年草)
使用部分:葉

スパイス
植物

特徴・使い方
肉の脂肪の臭みを消す働きがあるので、ソーセージやハンバーグなどのひき肉料理に使われます。
キャベツ、カリフラワー、コーンなどの温野菜料理や豆のスープなどにもあいます。
イタリア・ローマの名物料理である子牛と生ハムを使った「サルティン・ボッカ」という料理にも使われます。


551 :デフォルトの名無しさん:03/07/20 01:36
sage
a., n. 賢い; 賢人(ぶった).
sage・ly ━━ ad.
sage・ness ━━ n.
Seven Sages (of Greece) (the 〜) (古代ギリシアの)七賢人.

俺としてはこっち。

552 :デフォルトの名無しさん:03/07/20 13:37
パセリ sage ローズマリー タイム

553 :デフォルトの名無しさん:03/07/21 08:58

sageって言葉知ってる?

554 :デフォルトの名無しさん:03/07/21 13:06
>>552
スカボロフェアか

555 :デフォルトの名無しさん:03/07/22 02:55
IPアドレス取得についてすつもんです。
hostent 構造体のメンバ h_addr_list に入れてくれないIPアドレスがあるのですが
これはどういうことでしょうか。

2台のマシンでIPアドレス取得プログラムを走らせたんですが、1台目はOKで
2台目はグローバルなIPアドレスが格納されてないのです。

556 :デフォルトの名無しさん:03/07/22 03:55
>>555
とりあえずdigで、後者のホストでホスト名解決すると、
本当に二つのエントリがあるのかどうか調べてみては。

host1$ dig hostname
host2$ dig hostname

digの使っているlibraryも疑いたいならば、
host# tethereal -V port domain
して確かめてみれば?

557 :555:03/07/23 16:42
すいません。単なるNATの問題でした。

558 :デフォルトの名無しさん:03/07/29 18:20
保守

559 :デフォルトの名無しさん:03/07/31 19:22
別に落ちてもかまわないけど保守

560 :質問:03/07/31 19:23
ここの掲示板のCGIってどこで落とせるんですか?



無理ですか?

561 :デフォルトの名無しさん:03/07/31 19:28
WebProg
http://pc2.2ch.net/php/

562 :デフォルトの名無しさん:03/07/31 20:37
和田サンの進化を画像で見る

http://www.tanteifile.com/diary/2003/07/09/image/05.gif

563 :デフォルトの名無しさん:03/08/01 18:15
初めまして。
Perlでネットワークプログラムを組みたいんですけど、何か良い書籍とか知っている人いますか?
できればちょっとUGなことまで書いてある本捜してるんですけど

564 :デフォルトの名無しさん:03/08/01 18:33
>>563
セキュリティ
http://pc.2ch.net/sec/
WebProg
http://pc2.2ch.net/php/

565 :デフォルトの名無しさん:03/08/01 20:09
>564
すみません、板違いでしたね

566 :デフォルトの名無しさん:03/08/01 22:21
>>563
UGってなによ?

>>565
perlでSOAP叩くlibrary書くとかならここでもよか。

567 :デフォルトの名無しさん:03/08/01 22:33
>>566
あの白血病の特効薬見つける奴じゃないの?

568 :デフォルトの名無しさん:03/08/01 22:34
>UG
きっと夏休み語

569 :デフォルトの名無しさん:03/08/01 22:39
>>566
ライブラリなぞつかわずとも、自分でXML作って投げれば良かろう。

って言うか普通にMS-SOAP ToolKit使えばと。

570 :山崎 渉:03/08/02 02:08
(^^)

571 :デフォルトの名無しさん:03/08/02 04:45
>>569
透過的に使えないSOAPに何の価値があるというのか。

で、わざわざPerlでMS-SOAP ToolKitかよ。


572 :デフォルトの名無しさん:03/08/02 06:04
>>569は「ライブラリなんて使う奴は厨房」と言いつつ自分では#include<stdio.h>してる、よくいるDQN

573 :デフォルトの名無しさん:03/08/02 08:31
>>572
PHPでSAX使ってDOMもどき作ってSOAP通信を隠匿するクラスライブラリ書きましたが何か?

書かないのと書けないのとでは大違いというこった。


574 :デフォルトの名無しさん:03/08/02 13:21
>>566
> UGってなによ?
Under Ground、アングラでしょ。

575 :デフォルトの名無しさん:03/08/02 13:48
>>572
ヘッダーファイルとライブラリの区別が付かない厨房

576 :デフォルトの名無しさん:03/08/02 15:18
>>572じゃないが。

>>575
お前バカだな。

577 :デフォルトの名無しさん:03/08/02 15:34
stdio.hをincludeしたらどうなるか想像もつかないほどゆとりのあるインターネッツはこちらですか?

578 :デフォルトの名無しさん:03/08/02 16:37
よーするにCソースに
gcc -save-temps

cpp0
をかけて
*.iをみてみなさいってこった



>>577はいいたいそうです

579 :デフォルトの名無しさん:03/08/02 16:42
stdio.hの中身が展開されるだけだと思うけど。

580 :デフォルトの名無しさん:03/08/02 16:52
stdio.hはCの標準ライブラリが提供しているヘッダじゃないのか?
だったらstdio.hはライブラリの一部だろ。

581 :デフォルトの名無しさん:03/08/02 17:01
>>573は他人には「ライブラリなんか使わず自分でシコシコ書け」と言いつつ自分ではライブラリ書いてるDQN

582 :デフォルトの名無しさん:03/08/02 19:17
>>581
書いても使わない

583 :デフォルトの名無しさん:03/08/02 21:14
>>582
なるほど。作って捨てるわけか。阿呆だな。

584 :デフォルトの名無しさん:03/08/02 23:44
>>580
広義には (あるいはこじつければ) そうかも知れんが、普通にライブラリと言ったらヘッダファイルは含まん。

585 :デフォルトの名無しさん:03/08/03 00:12
なるほどSTLはライブラリに含まれないのか

586 :デフォルトの名無しさん:03/08/03 00:17
>>584じゃないが。

>>585
お前バカだな。

587 :デフォルトの名無しさん:03/08/03 01:19
>>585じゃないが。

>>586
STLって何の略か知ってるか?

588 :デフォルトの名無しさん:03/08/03 01:22
↓はりきってどうぞ。

589 :デフォルトの名無しさん:03/08/03 01:39
ほらな、ライブラリライブラリ言いながら標準ライブラリのことになると無知が多いだろ
>>586みたいな・・・

590 :デフォルトの名無しさん:03/08/03 02:37
ネットワークプログラミング相談室 Port6
主にソケットに関しての質疑応答スレです。

  - 再開 -

591 :デフォルトの名無しさん:03/08/03 08:16
STLがライブラリ?

まさかプロとか言わないよな?>>587

592 :デフォルトの名無しさん:03/08/03 08:35
>>585
なぜそこでSTLを出す?

593 :デフォルトの名無しさん:03/08/03 08:52



             誰とは言わないが 馬鹿がいます






594 :デフォルトの名無しさん:03/08/03 08:55
sageを知らない馬鹿か。

595 :GET!DVD:03/08/03 09:21
☆★ 新商品 ゾク・ゾク 入荷!! 急げ〜!! ☆★☆
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★ 送料激安!  スピード発送!  商品豊富!   
★☆      http://www.get-dvd.com        
☆★ 激安DVDショップ 「GETDVDドットコム」 
★☆      http://www.get-dvd.com        
☆★ 今すぐアクセス Let’s Go!   急げ! 
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★


596 :デフォルトの名無しさん:03/08/03 11:21
>>591
どう考えてもライブラリだろう。STLを何の略だと思ってるんだ。

597 :デフォルトの名無しさん:03/08/03 11:27
StringToLong

598 :デフォルトの名無しさん:03/08/03 11:34
StrictTypedLanguage

599 :デフォルトの名無しさん:03/08/03 11:54
素晴らしい竹田のララバイ

600 :デフォルトの名無しさん :03/08/03 12:01
STL形式とは?
 3次元CADのデータの形式の一つです。
STLは、「Stadard Triangulation Language」(標準三角パッチ言語)の略です。
STL形式は、特に光造形における標準ファイルフォーマットとして使用されています。


601 :デフォルトの名無しさん:03/08/03 12:51
>>600
なるほど

>>585>>596
プ

602 :デフォルトの名無しさん:03/08/03 12:53
>>585
> stdio.hはCの標準ライブラリが提供しているヘッダじゃないのか? (>>580)

誰も、C++ 話なんかしてないぞ。
それとも、最近は C でもテンプレートが使えるようになったのか ?

603 :デフォルトの名無しさん:03/08/03 14:14
>>602
(´`c_,'` )プッ
ヘッダにCコードが欠けることを知らない消防発見

add.h
--------------
int add(int i);
int add(int i)
{
i++;return i;
}
-------------- main.c
#include <add.h>
int main(int argc.char **argv){
int i=9;
add(i);
}


604 :デフォルトの名無しさん:03/08/03 15:25
>>603

なにか、必死な風味がするのぅ。
複数のソースで、そのタコヘッダーをインクルードして、コンパイル&リンクしてみたことある?

605 :デフォルトの名無しさん:03/08/03 15:31
ぷげらっちょ

606 :デフォルトの名無しさん:03/08/03 15:59
いい加減、スレ違いな話は止めようや。

607 :デフォルトの名無しさん:03/08/03 16:16
このスレってこういうので盛り上がるよね…。

608 :デフォルトの名無しさん:03/08/03 17:34
他のスレもけっこう夏っぽくなってるよ

609 :デフォルトの名無しさん:03/08/03 19:30
>>603
「こじつけ」っていう言葉知ってる ?

610 :デフォルトの名無しさん:03/08/03 19:39
夏ダカラ、コウナッタ

...歳がバレるな

611 :デフォルトの名無しさん:03/08/03 20:45
Cヘッダはライブラリファイルではないけどライブラリの一部だよ

612 :デフォルトの名無しさん:03/08/03 21:09
>>611
当たり前だろ。何言ってんだ。

613 :デフォルトの名無しさん:03/08/03 22:00
>>612
>>584みたいな奴が紛れてるから。

614 :デフォルトの名無しさん:03/08/03 22:08
>>613 (いや、分かってるんだよ。>>612>>584みたいな奴らに対する皮肉だよ)

615 :デフォルトの名無しさん:03/08/03 23:07
*.cもライブラリファイルじゃないがライブラリの一部

616 :デフォルトの名無しさん:03/08/03 23:46
ほんとに糞スレだな。
ネットワークプログラミング相談はどうしたんだよ。


617 :デフォルトの名無しさん:03/08/03 23:54
>>611-614
自演ご苦労。
ところで、「Cヘッダ」ってなんだ ?


618 :デフォルトの名無しさん:03/08/04 00:11
>>617=>>584
自分の敵は一人だ(自演してる)と思い込むのは助かりたくて必死である証拠だよ。
(ちなみに俺は>>612=>>614だが)

自分だけ意見が異なる際に「周りのみんなが変なんだ」と訴えるのは止めた方がいいよ。
「周りが変だ」じゃなくて「自分が変なんだ」だと気付かなきゃ。
間違いは誰でもあるよ。それを指摘されて素直に訂正できるかどうかが大事なんだ。まあガンバレ

619 :デフォルトの名無しさん:03/08/04 00:29
ライブラリの付属品だがライブラリの一部かどうかは・・・

620 :デフォルトの名無しさん:03/08/04 02:23
>>619
それ言い方変えただけやん

621 :デフォルトの名無しさん:03/08/04 02:53
とあるライブラリを落としたら.hのついたファイルが入ってました。いらないと思って消しました。

622 :デフォルトの名無しさん:03/08/04 04:03
お前らはこれがネットワークの話だと思ってるわけか。
大馬鹿だな( ´,_ゝ`)

623 :デフォルトの名無しさん:03/08/04 07:24
電波だからネットワークだろ?

624 :デフォルトの名無しさん:03/08/04 07:45
つまらん

625 :デフォルトの名無しさん:03/08/04 15:37
>>622
> お前らはこれがネットワークの話だと思ってるわけか。
> 大馬鹿だな( ´,_ゝ`)
これのどこがネットワークの話だ

626 :デフォルトの名無しさん:03/08/04 16:11
つまらん!おまいらの話はつまらん!

627 :デフォルトの名無しさん:03/08/04 17:09
>>557-560

628 :デフォルトの名無しさん:03/08/04 21:58
>>618
ハイハイわかったから、そんなに必死になるなよ。

629 :デフォルトの名無しさん:03/08/05 00:37
どうしてここはいつもこんなに殺伐としてるんだ?
ム板のスレってここしか見てないけど、どれもこんなん?
我が強い人が多いのね、プログラマーって。

630 :デフォルトの名無しさん:03/08/05 01:38
子供なだけだよ。面接で落とされる、もしくは職場で浮いているタイプ

631 :`c_,':03/08/05 03:46
>>630
おまえがな


632 :デフォルトの名無しさん:03/08/05 07:41
NWプログラマーは孤独なオシゴトだからバカになるんだよ

633 :デフォルトの名無しさん:03/08/05 10:08
だな。国内にはマトモなのが俺くらいしかいない。

634 :デフォルトの名無しさん:03/08/05 15:50
>>633
へぇ、すごいんですね!

635 :デフォルトの名無しさん:03/08/05 19:42
>>629
> どれもこんなん?
そんなことないよ・・・

636 :デフォルトの名無しさん:03/08/05 20:43
>>629
>>635

コーディング規約
http://pc2.2ch.net/test/read.cgi/tech/1056716338/
で 144 ◆O1EofOj10A が暴れてるよ。見てて面白いよー。
発端は
http://pc2.2ch.net/test/read.cgi/tech/1056716338/24-
だけど。24と144は同一人物かなー。


637 :デフォルトの名無しさん:03/08/05 22:39
selectで待つ前にlisten?

638 :デフォルトの名無しさん:03/08/06 05:48
そ。

639 :デフォルトの名無しさん:03/08/06 22:52
>>636
内容は良く分からんかったが、やりとりがおもろい。
なんとなく人物が想像できるなぁ。 144 ◆O1EofOj10A
きっと悪いやつじゃ無いんだよ。いぢめないであげよう!

640 :デフォルトの名無しさん:03/08/06 23:07
ボタンをクリックすると名前解決を行うプログラムで
最初だけ名前解決に失敗して2回目からはちゃんと
成功するのですが なじぇ?(゚▽゚;

struct hostent *hoste = gethostbyname("w3.monar.net");

if(hoste == NULL){
Memo1->Lines->Add("ほすと名の解決失敗(゚▽゚;");
}

641 :デフォルトの名無しさん:03/08/06 23:09
プログラマー
http://pc.2ch.net/prog/


642 :デフォルトの名無しさん:03/08/06 23:10
w3.monar.netってみつからないんだけど・・・

643 :デフォルトの名無しさん:03/08/06 23:14
・一発目はタイムアウト。
・二発目までに問い合わせ完了・キャッシュに入れとく
とか。

644 :デフォルトの名無しさん:03/08/06 23:15
ボタンをクリックすると名前解決を行うプログラムで
最初だけ名前解決に失敗して2回目からはちゃんと
成功するのですが なじぇ?(゚▽゚;

struct hostent *hoste = gethostbyname("w3.monar.net");

if(hoste == NULL){
Memo1->Lines->Add("ほすと名の解決失敗(゚▽゚;");
}

645 :デフォルトの名無しさん:03/08/06 23:16
>>644
miss gome

646 :デフォルトの名無しさん:03/08/06 23:17
>>640
www.monar.netでやっても結果は同じなのか?

647 :デフォルトの名無しさん:03/08/06 23:22
>>643
一発目はディレイがなくてタイムアウト
二発目はちゃんとディレイして解決!

ってのがはっきり分かるくらい違う

一発目でちゃんとディレイをいれて解決してほすい

648 :デフォルトの名無しさん:03/08/06 23:23
>>646
monar.netは違う関数を使って下さいとでました。

649 :デフォルトの名無しさん:03/08/06 23:24
>>648
gethostbyMonername() ですね

650 :_:03/08/06 23:27
http://homepage.mac.com/hiroyuki45/hankaku10.html

651 :デフォルトの名無しさん:03/08/07 00:02
分かった(゚▽゚;
ソケットオープンの後じゃないと失敗するんだ〜


652 : ◆TCP/IPmFAM :03/08/07 00:07
・・・(゚▽゚;

653 :デフォルトの名無しさん:03/08/07 01:12
socketのopen?

winsockのinitialize前といいたい?

654 :デフォルトの名無しさん:03/08/07 01:45
>>653
socket関数の直後です

655 :_:03/08/07 01:48
http://homepage.mac.com/hiroyuki45

656 :デフォルトの名無しさん:03/08/07 09:57
とりあえず、example.net を使え、と。

657 :デフォルトの名無しさん:03/08/08 19:16

Webサーバ(Apache)からlzhやexeファイルを受信するソフトを作ってるんだけど、
とりあえず設置してhttp://hoge.hoge.hoge/hoge.lzhとIEでアドレスを指定するとおっこってくるのね。

受信できる事を確認した上で、
自分のSoftでつないでGETで受信しようとすると、エラー(503だったかな?)が返ってくる。
でもlzh,zip意外・・たとえばjpg等に改名すれば自分のソフトでも受信できる。
どこが悪いのかな?

GET\r\n\r\nで受信しようとしてるんだけど、2回目の改行の前に何か入れなきゃダメ?
ほかには、.htaccessにAddTypeを追加したり色々してるんだけど上手く遺憾。


658 :デフォルトの名無しさん:03/08/09 00:08
>>657
> エラー(503だったかな?)が返ってくる。

「だったかな?」じゃねーだろよ。
ちゃんとみれ

659 :デフォルトの名無しさん:03/08/09 01:40
とりあえず、投げたリクエストヘッダと返ってきたレスポンスヘッダを
全部提示しろ。

660 :デフォルトの名無しさん:03/08/10 01:58
あの
質問なのですが、バイナリ変換してパケットを送信する際に
intの場合”2 の補数表現で符号化したものをバイナリ値とする”
とかで変換する必要があるって記述があるけど実際には
2の補数表現を用いずそのまま送信しているケースってありますか?

定義されているにも関わらずです

661 :デフォルトの名無しさん:03/08/10 02:01
プロトコル破りをするクライアントが存在する可能性は常にある。
そういうクライアントの辿る運命は誰も知らない。

662 :デフォルトの名無しさん:03/08/10 02:14
>>661
根本的な質問で申し訳ないのですが
例えば0000 0001 の2の補数表現は
1111 1111で正しいですか?これを1としてパケットのバッファ
に挿入する事が正しいのでしょうか?

 超有名どころのオープンソースのクライアントは
2の補数表現を用いず 0000 0001としてそのまま送信しています。

定義は2の補数表現を用いろと言っているにも関わらずです。

一体どちらが正しいのでしょうか?
一番可能性が高いのは2の補数表現というものを私が勘違い
している事です。


663 :デフォルトの名無しさん:03/08/10 02:18
>>662
1の2の補数表現は0000 0001だろ。1111 1111は-1

664 :デフォルトの名無しさん:03/08/10 02:19
2の補数表現 <=> 1の補数表現
これは負の値の表現方法の違いで、1はどっちでも00000001なわけ。
>”2 の補数表現で符号化したものをバイナリ値とする”
これは、ふつうに読めば、「負数の表現は2の補数でやってね」としか読めない。
わざわざ正数Xを負数にした上で、2の補数表示をする必要はない。

665 :デフォルトの名無しさん:03/08/10 02:22
>>663
やっぱりTT
数学の教科書買ってきます



666 :デフォルトの名無しさん:03/08/10 02:25
>664
そゆことなんですねTT
Eatherealがいくら符号なしで表示しようと
鯖側で復号されていると信じますTT

667 :デフォルトの名無しさん:03/08/10 02:27
>>665
わざわざそんな本いらんよ。
適当にぐぐれば説明出てくるかと

668 :デフォルトの名無しさん:03/08/10 02:29
数学なの?

669 :デフォルトの名無しさん:03/08/10 02:31
>>667
基本はぐぐって勉強してるんですが
基本的な部分が分かってなくて変な所で勘違い
しちゃってハマるとつらいっす(今回が良い例なのですが..)
本当のとこ どうなんだろ〜って永遠の悩みに突入しちゃうw

670 :デフォルトの名無しさん:03/08/10 02:36
勉強の仕方がおかしい

671 :デフォルトの名無しさん:03/08/10 02:42
>>669
補数表現=ビット列のいちばん左が1なら全ビットを反転させて-1した数の負の値とする、って感じか。
1000 0100なら普通なら128+4=132だけど、補数表現だと負なのでまず全ビット反転して0111 1011、
それから-1すると0111 1010、これは122を表すが、これに-をつけたもの(-122)が1000 0100の表す値。

672 :デフォルトの名無しさん:03/08/10 02:45
>>671
+1じゃないか?

673 :デフォルトの名無しさん:03/08/10 02:47
>>671
ですね アリ^^

2の補数というのが何者なのか理解できていなかったので...
概念が分かっていないのが苦しい..w

674 :デフォルトの名無しさん:03/08/10 02:50
>>673
あの つまり 慣れてないんですw

675 :デフォルトの名無しさん:03/08/10 02:52
>>672
正→負、負→正、どっちも+1だったのか… 間違って覚えてたよ、ものすげえ鬱だ…( ´Д⊂ヽ
これを直接やるプログラムを今まで書く機会がなかったのが唯一の救いと言うべきか

676 :デフォルトの名無しさん:03/08/10 02:56
1000 0100は-124だな。

677 :デフォルトの名無しさん:03/08/10 03:09
こんなネタで盛り上がるなよ

678 :デフォルトの名無しさん:03/08/10 03:20

   /⌒ヽ
  / ´_ゝ`)ここ通らないと行けないので、ちょっと通りますよ・・・
  |    /
  | /| |
  // | |
 U  .U


679 :デフォルトの名無しさん:03/08/10 10:23
激しくスレちがい。
聞くほうも聞くほうなら
答えるほうも答えるほう。

680 :デフォルトの名無しさん:03/08/10 10:39
そして679は気違いと。

681 :デフォルトの名無しさん:03/08/10 10:46
データをバイナリで送るときは符号ではなく、バイトオーダーに気を付けるべき

682 :デフォルトの名無しさん:03/08/10 11:21
>>681
その辺吸収してくれるのがソケット君では?

683 :デフォルトの名無しさん:03/08/10 11:35
>>682
ソケット君はバイトストリームだから面倒みてくれないよ。

684 :デフォルトの名無しさん:03/08/10 12:34
>>683
意地悪でつね。ソケット君。

685 :デフォルトの名無しさん:03/08/10 13:17
中学のメル友とネットワーク越しにセックスしたいのですが
どうしたらいいですか?

686 :デフォルトの名無しさん:03/08/10 13:25
電話でやれ

687 :デフォルトの名無しさん:03/08/10 13:35
>>685
あなたのコネクタはIEEE規格を満たしていないので無理です

688 :デフォルトの名無しさん:03/08/10 13:36
>>687
僕のパラレルポートも閉鎖されそうです!

689 :デフォルトの名無しさん:03/08/10 16:20
音声チャットでテレホン(?)セクースならたまにやるよ。

690 :デフォルトの名無しさん:03/08/10 17:49
おまえら全員氏ね

691 :デフォルトの名無しさん:03/08/10 19:05
無料
ttp://www.girlsonair.tv/


692 :デフォルトの名無しさん:03/08/10 20:05
激しくスレちがい。
聞くほうも聞くほうなら
答えるほうも答えるほう。

693 :デフォルトの名無しさん:03/08/10 20:27
selectで

694 :デフォルトの名無しさん:03/08/10 22:10
electで

695 :デフォルトの名無しさん:03/08/11 01:45
ハァハァ

696 :デフォルトの名無しさん:03/08/11 01:47
これもあげておこう。

697 :デフォルトの名無しさん:03/08/11 11:55
>>684
RPC君に助けを求めなさい

698 :デフォルトの名無しさん:03/08/12 16:58
質問です
IPアドレスのリストにgethostbyaddrをかけて順次ホスト名を得ようとしています。
ホスト名が引ける場合はいいのですが、ホスト名が無い等で引けない場合が遅いので、イライラしちゃいます。
速度アップの方法はないでしょうか
例:ホスト名を引けるか引けないかだけを知るより高速な関数を使って調査し、引ける場合にgethostbyaddrする とかね


699 :デフォルトの名無しさん:03/08/12 17:04
DNSだけなら、直接クエリを投げた方が早い気もする。
djbのdnsfilterを参考にしてみたら?

700 :デフォルトの名無しさん:03/08/12 17:21
>>698
否定的であれ肯定的であれすぐに返事が来るときはいいのですが、
返事が来ない場合、単に遅いのか、それとも答えるべきサーバが落ちてるのか分かりません。

だからタイムアウト処理をして、それを唯一の根拠とする必要があります。
DNSなら、>>699の上げている奴以外には、ares, adnsなどのlibraryが使えます。
http://packages.debian.org/unstable/libdevel/libares-dev.html
http://packages.debian.org/unstable/libdevel/libadns1-dev.html

701 :698:03/08/12 17:38
>>699-700
ありがとうございます。
せっかく回答いただいたのに活用できません。申し訳ないです。
問題はですねー当方がVCL厨だってことなんです。
よってですね、>>700氏のタイムアウト処理でスレッド破棄の方法でいくことにします。
ありがとうございました。

702 :デフォルトの名無しさん:03/08/13 13:07
質問お願いします。ネットプログラムの勉強も進み、そろそろ自分でも何か…
と思い、友人同士で話せる簡単なチャットソフトを作ってみました。

ところが繋がったり繋がらなかったりでして…。
自分なりに調べてみたら、どうもグローバルIPだの
ルータだのと、個人同士で接続するには色々壁があるみたいで…。

手持ちの本を調べてみても、127.0.0.1とか、httpでgetみたいな
話ばかりで、この辺りの機微については触れていない物ばかりです。
よろしければ、個人での接続に詳しい、サイトや本を紹介して頂けないでしょうか。

703 :702:03/08/13 13:07
すいません、いつものくせでsageてしまいました

704 :デフォルトの名無しさん:03/08/13 13:13
http://www.amazon.co.jp/exec/obidos/external-search?tag-id=undergroundpubli&index=all&keyword=ADSL%20%E5%B8%B8%E6%99%82%E6%8E%A5%E7%B6%9A

705 :デフォルトの名無しさん:03/08/13 13:16
http://www.rtpro.yamaha.co.jp/RT/docs/game/index.html


706 :デフォルトの名無しさん:03/08/13 13:49
>702
機微ってか、HowToを読んで場当たり的にやっていればいずれ行き詰まるのはあたりまえ。
個人での接続うんぬんの解説もいいが、それも結局はHowToでしかなく、いつかまた行き詰まるよ。
結局のところネットワークの基本的な動作を理解する以外に近道は無い。

って事で
ttp://www5e.biglobe.ne.jp/~aji/3min/


707 :デフォルトの名無しさん:03/08/13 14:02
>>706
>結局のところネットワークの基本的な動作

所為規模の場合はベースバンドでの通信が一般的とかそんなん?


708 :702:03/08/13 14:20
>>704-706
すいません、思わずリンク先読み込んでレスが遅れました。
いやはや、どれも素晴らしくて…ありがとうございました。

>>706
仰るとおりで、自分でいじれそうな箇所以外は興味持てなくて…。
授業(まだ般教程度ですが)でも基礎から教わったはずなのですが、全く記憶になく…。
心入れ変えて、リンク先からじっくり始めてみます。心から感謝です。

709 :デフォルトの名無しさん:03/08/13 14:25
クラスA争奪戦に敗北した日本が全て悪い。

710 :デフォルトの名無しさん:03/08/13 15:16
(゚Д゚)ハァ?

711 :デフォルトの名無しさん:03/08/13 16:26
>>708
大学で本格的にやるような人が、基礎から行くなら、>>3にある
>> 詳解TCP/IP〈Vol.1〉プロトコル
>> http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
からやるのがいいです。

> リンク先からじっくり始めてみます。

急がば回れ、ですよ。

712 :デフォルトの名無しさん:03/08/13 16:55
高々チャットアプリごときで詳細勧めるなよ。

713 :702:03/08/13 20:52
>>712
やー、とんでもないです。今ようやく全て読み終わった所ですが
私なんかでも、かなり理解を深めることができました。

自IPアドレス(218.〜)を見たところ、どうやらプライベートIPアドレスでは無い様です。なので、
チャットソフトは、とりあえず、うち側を必ずサーバにする形で作り直してみたいと思います。

>>711
最短ならぬ、最適ルートの提示ありがとうございます。
実は専攻では無いのですが、俄然興味でてきました。
ちょと値段が高いので、とりあえずうちの図書館見てきます。感謝です。

714 :デフォルトの名無しさん:03/08/13 21:11
>>713
C-S--------------------------------------C

715 :デフォルトの名無しさん:03/08/14 00:22
IPv6なんですが、
TCPでリンクローカルアドレスは使えるんですか?

Linuxのping6では、

ping6 fe80::XXXX:XXXX:XXXX:XXXX%eth0

のようにやるとうまく通信できるんですが、
ttp://garrett.damore.org/software/ethernet/index.shtml
にあるIPv6対応ttcpではTCPのときにうまく動きません。
(UDPのときはうまく動いています。)

実行したコマンドは、

(受信側)
ttcp -r -6 -s

(送信側)
ttcp -t -6 -s fe80::XXXX:XXXX:XXXX:XXXX%eth0

ってな具合です。
これをやると、受信側ではlistenまで完了するのだけど、
acceptがどうもできてないみたいです。

分かる方、よろしく。


716 :デフォルトの名無しさん:03/08/14 00:29
というか、複数相手には3-way-handshakeが通らないと思うのだが。

717 :デフォルトの名無しさん:03/08/14 00:30
あかん、ぼけてた。

718 :デフォルトの名無しさん:03/08/14 03:38
☆★☆★ 海外サイトだから安心無修正 ★☆★☆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html
☆★☆★ 本気汁丸出しのお○○こが! ★☆★☆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html
☆★☆★ 2日間無料丸見え体験実施中 ★☆★☆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html

 ↑ ↑ ↑
これって2日間ダウンロードしまくって
そのあと解約すれば全然タダじゃん?

719 :デフォルトの名無しさん:03/08/14 05:07
ルーター(Linux)[192.168.0.2]と
クライアントマシン[192.168.0.1]があって
ルーターがISPにつなぎます
クライアントがNATをつかい外のイントラトネットを見るとき
クライアントマシンがルーター側のISPからもらったIPを調べる関数みたいなものはないのでしょうか。


720 :デフォルトの名無しさん:03/08/14 05:15
>>719
頑張れ若造

721 :デフォルトの名無しさん:03/08/14 05:23
>>719
ネットワークプログラミングってネットワークに関する
知識と経験が必要なんだわさ
 まずネットワークの構築経験をある程度積んでからの
方が良いとおもわれ

722 :デフォルトの名無しさん:03/08/14 05:27
>>720
>>721
いいからはよこたえろやぼけ
SYSフラッド撃つぞコラ

723 :722:03/08/14 05:29
gethostbyaddrで所得できますかね

724 :デフォルトの名無しさん:03/08/14 06:04
確か以前にも出た質問だね。
その時はまじめに答えていたと思うけど。

725 :724:03/08/14 06:07
このスレではなかったかも。


726 :デフォルトの名無しさん:03/08/14 07:56
>>721
そうでもないと思うが、まぁ、無ければそのうち困ることになるな。


727 :デフォルトの名無しさん:03/08/14 08:02
>>725
過去スレ

>>719
http://checkip.dyndns.org

728 :719:03/08/14 08:05
>>727
だからなに?
全然いいたいことがわからない
プログラム内で調べられるか聞いてんだよボオオオオオケ
カーネルに問い合わせでもしない限り無理なの?

729 :Not 727:03/08/14 08:12
>>728
本物の719?
いくらなんでも失礼じゃないか?

730 :デフォルトの名無しさん:03/08/14 08:27
>>729
お前も釣られるなよ。

731 :デフォルトの名無しさん:03/08/14 09:11
よっぽど暇でかまいたくなったものと思われ

732 :デフォルトの名無しさん:03/08/14 09:17
・Winny機能強化バージョン
UP0、DL13、ポート警告100、1時間リセットOFF、PORT0検索リンク5、PORT0転送帯域制限無
ホニャララトホテップ http://home.graffiti.net/nyarlathotep/
Winny114patch.zip 246,465 4f69fa0ba21a1b423aeb8e1057ac86f6

・CRACKED版を使いたくない場合
プロセスメモリエディタで42EBA5からのアドレスを次のように書き換える
42EBA5:B8 0A 00 00 00 89 86 D8 37 00 00 89 86 DC 37 00 00 EB 18 (←DL10の場合)
42EBA5:B8 FF 00 00 00 89 86 D8 37 00 00 89 86 DC 37 00 00 EB 18 (←DL255の場合)

・折井(OllyDbg)でアタッチしてうぷ本数変更する方法
WINNY1.14を折井で開きCPU窓で書き換えれば、うぷ本数変更可能。
但し速度制限は解除できてない諸刃の剣。なので>4121B8:EB

・バージョン警告を消す
0042F427 MOV BYTE PTR DS:[EDI+3824],1 → ....,0

733 :デフォルトの名無しさん:03/08/14 10:21
>>719 はどういう事情があって、そういうことが必要なのか
その背景を説明したほうがいいかもね。


734 :デフォルトの名無しさん:03/08/14 10:26
UPNPを使えば取得可能
以上

735 :デフォルトの名無しさん:03/08/14 11:15
DiCEはUPnP使ってるようには見えないが取得できてるぞ

736 :>>727:03/08/14 11:22
>>728
>>727がどんな環境でも必ず成功する方法です。

Routerが対応していれば、UPnP(>>734)が使えますがLinuxなんでしょ?
LinuxもUPnP使えるけど、setupされてるのかな?
http://upnp.sourceforge.net/

いずれにせよ、

> プログラム内で調べられるか聞いてんだよボオオオオオケ
> カーネルに問い合わせでもしない限り無理なの?

陰であれ陽であれ、protocolの世話にならないといけない。
別の機械の設定だからね。

Linux側でsnmptd上げれば、SNMPも使えるよ。


737 :デフォルトの名無しさん:03/08/14 11:26
>>733
2ちょんねるにperlで書き込みのスクリプとを書きたいのです

socket(SOCKET,2,1,0);
setsockopt(SOCKET,SOL_SOCKET,SO_KEEPALIVE,1);
unless(connect(SOCKET,$address)){return 1;}
my $mysockaddr=getsockname(SOCKET);
my($myport,$myaddr)=unpack_sockaddr_in($mysockaddr);
my($name,$aliases,$addrtype,$myiplength,@myaddrs)=gethostbyaddr($myaddr,AF_INET);
my $Cookie_Host="$name;";
select(SOCKET);
$ |= 1;
select(STDOUT);
print SOCKET "$HTTP_CMD $filename HTTP/1.0\r\n";
print SOCKET "Connection: close\r\n";
print SOCKET "Content-Type: application/x-www-form-urlencoded\r\n";
print SOCKET "Content-Length: $CL\r\n";
print SOCKET "Cookie: $Cookie_Mail\r\n";
print SOCKET "Cookie: $Cookie_Host \r\n";

ルーター介すまではこれでよかったんですが
$Cookie_HostにとにかくISPからもらったホスト名をいれないといけません

738 :>>727:03/08/14 11:27
>>735
だって、あれはdynamic DNSのサイトに登録するわけでしょ?
登録しに行けばサーバはこっちのアドレス分かるわな。

>>727みたいにこっちで調べてから登録することも出来るしね。

739 :>>727:03/08/14 11:35
荒しスクリプトか…

740 :デフォルトの名無しさん:03/08/14 11:39
>>739
アラシジャネーヨ
わからんなら消えろやリア厨が

741 :デフォルトの名無しさん:03/08/14 11:41
age2chでも使ってろ

742 :デフォルトの名無しさん:03/08/14 11:51
>>738
うんにゃ、起動するだけで外部サーバには一切つなぎに行かないで
取得できる。どんな環境でも100%ではないみたいだが。

743 :デフォルトの名無しさん:03/08/14 11:56
クッキー偽造しようってんだから荒しだろ。
まっとうなプログラムなら、保存しておいたクッキーをそのまま送るだけじゃん。


744 :デフォルトの名無しさん:03/08/14 12:00
保存しておいたクッキー?

745 :デフォルトの名無しさん:03/08/14 12:10
お前、クッキーの意味知らないのか?

RFC読め。
俺様は親切だから、番号も教えてやる。 RFC2965だ。 感謝しろ。

それでもわかんなきゃ、ここ読め。
ttp://tohoho.wakusei.ne.jp/wwwcook.htm


746 :719:03/08/14 12:17
いやつーか>>732
は俺がつくったスクリプトだからクッキーぐらいしってるが

747 :デフォルトの名無しさん:03/08/14 12:17
そうじゃなくて
>>727のどこが保存したクッキーと関係あるのさ
IP表示してるだけに見えるんだが。

748 :749:03/08/14 12:17
>>732じゃなくて>>737

749 :デフォルトの名無しさん:03/08/14 12:21
1回Cookieなしで書き込めばSet-Cookieヘッダに何を設定すべきか
返ってくるだろ。それを設定してリトライすればいい。
グローバルIPを取得する必要がどこにあるの?

まあそれはそれとして漏れはDiCEがどうやってグローバルIPを取得
してるのか知りたい

750 :デフォルトの名無しさん:03/08/14 12:22
「クッキーの偽造」がしたいのでIPアドレスが知りたいんだろ?
違うのか?


751 :デフォルトの名無しさん:03/08/14 12:25
書き込めりゃ別に手段はクッキーの偽造でなくてもいいんだろ。

752 :デフォルトの名無しさん:03/08/14 12:28
きっと「クッキー」の意味も知らないし、RFCも読む気が無いようだから教えてやる。

クッキーはサーバが作って、クライアントに押し込むものだ。
クライアントは次にサーバにアクセスするときに、
サーバから受け取ったクッキーをそのままくっつけてリクエストする。

クライアントがクッキーを自分で作成するなら、それは「偽造」だ。


753 :デフォルトの名無しさん:03/08/14 12:33
だから>>749前半のようにやれと言ってるわけだが

754 :>>727:03/08/14 13:04
>>749
> まあそれはそれとして漏れはDiCEがどうやってグローバルIPを取得
> してるのか知りたい

Linux$ cat DiCE/ipcheck.dat
http://www.hi-ho.ne.jp/cgi-bin/user/yoshihiro_e/ip_check.cgi
http://www.dyndns.org:80/cgi-bin/check_ip.cgi


755 :デフォルトの名無しさん:03/08/14 13:30
UPnPってXPならAPIがあるけどそれ以前では自分で
プロトコル実装するしかないんですか?
Linuxみたいに誰かがSDK公開してくれてたりしません?

756 :デフォルトの名無しさん:03/08/14 14:08
>>755
一応突っ込んでおくとUPnP自体はOS非依存。
って言うかUNIX向けライブラリがMSかIntelから出てた気がする。

757 :>>727:03/08/14 15:07
>>756
> Intelから出てた気がする。

>>736
> http://upnp.sourceforge.net/

In 2000, Intel created the first version of the Linux SDK for UPnP Devices and
subsequently released it to the open source community to foster growth of UPnP.


758 :デフォルトの名無しさん:03/08/15 00:08
>>719
これに釣られる奴はあかんな〜

759 :デフォルトの名無しさん:03/08/15 01:08

>>719

キモイ

760 :デフォルトの名無しさん:03/08/15 01:21
>>719
> ルーター(Linux)[192.168.0.2]と
> クライアントマシン[192.168.0.1]があって
> ルーターがISPにつなぎます
> クライアントがNATをつかい外のイントラトネットを見るとき
> クライアントマシンがルーター側のISPからもらったIPを調べる関数みたいなものはないのでしょうか。

NATが分かっててこんなアホな質問するかよ
こういう初心者を装った板アラシなんとかならない?
>>719

でてきて説明してみろよ ええ?

761 :デフォルトの名無しさん:03/08/15 01:40
>>722
> >>720
> >>721
> いいからはよこたえろやぼけ
> SYSフラッド撃つぞコラ
>>723

は同一人物で煽りと正常なタイプで一人二役だよ

この板クッキーいれてよママ

762 :デフォルトの名無しさん:03/08/15 02:04
SYNフラッド?
SYSフラッド?


763 :デフォルトの名無しさん:03/08/15 09:31
>>760
結局、その程度の相手にしか自分を優位に見せることが出来ないんですね。

764 :山崎 渉:03/08/15 15:27
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

765 :デフォルトの名無しさん:03/08/15 20:25
>>763
> >>760
> 結局、その程度の相手にしか自分を優位に見せることが出来ないんですね。

優位なのか?技術だけはものすごくて詐欺師的な事をあちこちでやってる
かもしれんよ 自分が理解している質問を板に投げて釣られている奴みて
ほくそ笑んでいるんだから普通に警告してるのだが


766 :デフォルトの名無しさん:03/08/15 22:40
ageておこう

767 :デフォルトの名無しさん:03/08/17 14:24
>>754
そんなファイルないが?

768 :デフォルトの名無しさん:03/08/18 14:49
通信を行っているプログラムが別途あって、それが使用している
ソケットの状態とポートの状態を定期的チェックしたいんですが、
GetTcpTable および GetUdpTableで取得できるステータスで判
断すればいいのでしょうか?

下記の状態くらいがわかればいいのですが。
ソケットの状態:接続中、未接続
ポートの状態 :OPEN、CLOSE

OS:WIN2000
開発言語:VB6

よろしくお願いします。


769 :デフォルトの名無しさん:03/08/18 22:42
>>768
netstat

770 :デフォルトの名無しさん:03/08/19 09:37
>>769
ツールが知りたいんじゃなくて、自分で作りたいんですけど。

771 :デフォルトの名無しさん:03/08/19 09:46
>>770
んじゃおとなしくC使え

772 :デフォルトの名無しさん:03/08/19 10:23
>>771
Cでもいいけど関数教えて。

773 :初心者:03/08/19 10:50
質問です,具体的にはCで開発は行ってないのですが.仕組みを教えていただきたいのです
よくWinMXやWinnyなどは複数のファイルを同時にダウンロードできるようになっていますが
あれはどういった仕組みになってるんでしょう?
マルチスレッドにして異なるクライアントに同時に応対できるようにはわかるのですが
一つのクライアントから同時に二つのリクエストを受けたときにはスレッド内で
さらにスレッドを作って応対すればよいのでしょうか?
何方かアドバイスしてくれませんか?


774 :デフォルトの名無しさん:03/08/19 10:53
>>773
select関数

775 :デフォルトの名無しさん:03/08/19 10:54
Win32だと WaitForMultipleObject() かな。
必要なだけスレッド作ってもいいけど。


776 :初心者:03/08/19 11:36
>>773
えっとselectつかうということは,複数のソケットを管理するときですよね?
ってことはWinnyやWinMXは複数のファイル送受信のときは複数のソケットを
socket関数で作っているということですか?
それとも一つのソケットにたくさんの出入り口があるということなのでしょうか?
お馬鹿ですみません(汗

777 :デフォルトの名無しさん:03/08/19 11:58
>>776
複数のソケットをあつかってんだろ。
それがなんか不思議なのか? ごく自然な発想に思うけど。


778 :初心者:03/08/19 12:01
>>777
ということは…サーバーはファイルのリクエストがあったたんび
にポートを空けてListenするということに?

779 :初心者:03/08/19 12:04
>>778
ああ違います,馬鹿なこと言ってました.
えっとつまりクライアントは多重ダウンロードしている数の分だけsocketをつくって
サーバーにconnectしてファイルを受けている
ということでしょうか?

780 :デフォルトの名無しさん:03/08/19 12:20
んなこといちいち質問してるレベルじゃ永遠に完成しないな

781 :デフォルトの名無しさん:03/08/19 12:22
ひとつのソケットの中を複数のストリーム流そうが、
複数のソケットを開こうが、
どっちでもかまわない。
プロトコルで決めることだろう。

俺はしみったれだから複数のソケットを開こうとは思わないけど。


782 :初心者:03/08/19 12:42
なるほど,どうもありがとうございました!

783 :デフォルトの名無しさん:03/08/19 17:25
つーか、WinMX とか Winny で同一ホストから多重ダウンロードなんかしないと思うぞ。
(ほとんど意味ないだろ。)
だから複数ソケット使うしかないと思うが。

784 :初心者:03/08/19 17:56
>>783
いぇ多重ダウンロードというのはそういう意味じゃなくって
同じサーバーから同時に二つ以上のファイルをダウンロードするという意味
で使ったんです
別にP2Pのプロトコルを使ってるわけじゃないんです(^_^;
クライアントサーバーアプリケーションです

785 :デフォルトの名無しさん:03/08/19 21:25
>>784
だったら、「よくWinMXやWinnyなどは...」なんて書くなよ。
自分でプロトコル作る気があるなら、>>781 の言うようにどうとでもできる。
まあせっかく tcp と言う優れたストリームプロトコルがあるんだから、普通は複数ソケットだろうな。
マルチプロセス/スレッド が使えるならそのほうが作りやすいし。

786 :初心者:03/08/19 22:06
>>785
よかれとおもって出したたとえが悪かったようですごめんなさい

私は,ひとつのソケットの中を複数のストリームを流すという方法をとりたいです
…クレクレ君で申し訳ないんですけど…
どうやって複数のファイルを区別しようかなぁ…それぞれのパケットにオリジナル
のヘッダをつけようか…

787 :デフォルトの名無しさん:03/08/19 22:19
>>786
>それぞれのパケットにオリジナルのヘッダをつけようか…

udp でやる気か ?

そんな知識しかないなら、悪いこと言わんから素直に tcp 複数ソケットでやっとけ。

もしこれ以上質問するなら「何のために "ひとつのソケットの中を複数のストリームを流すという方法をとりたいです"」をきちんと説明してからにしてくれ。

788 :デフォルトの名無しさん:03/08/19 22:19
>>786
ネタ?

789 :デフォルトの名無しさん:03/08/19 22:34
>>786
無理ですよ。そんなこと。
もしできたとしても伝送路は結局のところ一本なわけで誰も得はしないでしょう。


790 :初心者:03/08/19 22:35
>>787
ソケットを複数開くとその分メモリ食いませんか?
なんか無駄な子とやっているような気がしてならないのですが…
違うんでしょうか?
ポートも使いますよね?クライアント

791 :デフォルトの名無しさん:03/08/19 22:36
>>790
喰いますけど、それが何か?

792 :初心者:03/08/19 22:37
TCP複数ソケットでやるということは,一つのクライアントで
何個もサーバーにコネクトするということですよね?
ということはサーバーのほうもその都度いちいちコネクトしてきたときの応対
処理をしなきゃいけないでしょうし無駄じゃないのでしょうか?

793 :デフォルトの名無しさん:03/08/19 22:38
>>790
お前はまず既存のプロトコルを使ったクライアント・サーバーを作れ。

794 :初心者:03/08/19 22:40
>>793
FTPとかHTTPとかですか?
でも今のソフトもうほぼ完成状態なんです(汗
いま複数のファイルの同時ダウンロードは無理ですが
一つのファイルならダウンロードはできます.

795 :デフォルトの名無しさん:03/08/19 22:41
>>793
何層のことを言ってるんだろうか・・・ <既存のプロトコル

796 :初心者:03/08/19 22:41
下手にでりゃ良い子になりやがって

797 :初心者:03/08/19 22:42
>>796
は偽者ですよw
とリップつけようかな…

798 :デフォルトの名無しさん:03/08/19 22:42
>>796
いいことじゃねぇか。

799 :初心者 ◆HpoMMhy6mE :03/08/19 22:44
トリップつけました

800 :デフォルトの名無しさん:03/08/19 22:44
>>798
ワラタ
796は微妙に意味不明だなw

801 :初心者 ◆s/YG.IU0L6 :03/08/19 22:52
閑話休題

802 :初心者 ◆HpoMMhy6mE :03/08/19 22:54
socket複数接続ってのはかなりメジャーな手なのですか?
自分はネットワークプログラミングの経験は殆どないので…
今までは一つのソケットに複数のストリームを流すのが吉とおもってました

803 :デフォルトの名無しさん:03/08/19 23:05
さっさと作れよ

804 :デフォルトの名無しさん:03/08/19 23:07
>>802
>>787

805 :デフォルトの名無しさん:03/08/19 23:32
>>804
今までのレスに書いてあるだろが。

806 :デフォルトの名無しさん:03/08/19 23:41
>>805
ぜんぜん分からん

807 :デフォルトの名無しさん:03/08/19 23:43
>>790
複数ストリームをひとつのソケットでやると、その複数ストリームの制御のためにそれなりのメモリーを喰うだろ。
要は多重化を誰がやるかだけの問題だと思うぞ。

きちきちに設計すりゃ複数ソケットより実行/メモリー効率のよい実装ができるかもしれないけど、ほんとにそこまで必要なのか ?
ポートも使うけど、それがに問題になるほど多重化するのか ?

学習のためにやりたいと言うなら止めないけど、実用ならやめとけ。

ほんとにメモリー効率/ポート数の制限が厳しいようなシステムの設計を任されているなら、「できない」と言って断れ。

808 :デフォルトの名無しさん:03/08/19 23:44
>>806
誤爆かどうかも分からない馬鹿発見

809 :初心者 ◆HpoMMhy6mE :03/08/19 23:47
>>807
なるほどわかりました

みなさん私の質問に最後まで付き合っていただいて恐縮です.
複数ソケットを使って実装してみますね.

ありがとうございましたm(_ _)m

810 :デフォルトの名無しさん:03/08/19 23:49
オマエらはHTTPのパーシステントコネクションや
リクエストパイプラインのことを知らないようでつね(w

811 :デフォルトの名無しさん:03/08/19 23:50
>>810
それは並列ではなくて順次処理

812 :デフォルトの名無しさん:03/08/19 23:54
リクエストパイプラインは並列でつよ(w

813 :_:03/08/19 23:56
http://homepage.mac.com/yamazaki8

814 :デフォルトの名無しさん:03/08/19 23:56
>>812
順次です。
persistent connectionはソケットを再利用するためのもの。
またpipelineは応答待ち時間を削減するのが目的。

815 :デフォルトの名無しさん:03/08/19 23:58
並列処理なら

fork
pthread
select



816 :デフォルトの名無しさん:03/08/20 00:38
あんまり沢山コネ張ってもスループット上がらないような。
SCSIみたいにリクエストのタグ付きキューイングができればいいんだろうけど、
それはそれで実装が複雑になるからねえ・・・

817 :デフォルトの名無しさん:03/08/20 06:24
>>816
略語で通ぶろうという魂胆ですね?

818 :デフォルトの名無しさん:03/08/20 06:24
>>816
気にしなくてもTCPがやってくれている。

819 :デフォルトの名無しさん:03/08/20 21:56
Windows上でQoSに関するソフトウェア作る際のプログラミングの資料ってどこにありますか?

820 :デフォルトの名無しさん:03/08/21 01:00
これ、いつ出るんだろ?
http://www.kumei.ne.jp/c_lang/bookinfo/yokoku01.htm

821 :デフォルトの名無しさん:03/08/21 07:49
>>820
買うまでもない。初心者向けだろ?

822 :デフォルトの名無しさん:03/08/21 11:14
メールヘッダーの↓の-0400とかの意味や種類が書いているHPを教えて下さい
Date: Wed, 21 Aug 2002 08:10:32 -0400 (EDT)
Date: Wed, 28 Aug 2002 10:39:20 +0900 (JST)
Date: Sat, 18 Jan 2003 02:52:46 -0700


823 :デフォルトの名無しさん:03/08/21 11:35
>>822
レス番号が822なのは狙ってやったのだろうか…
RFC2822 (旧RFC822) を読みなさい。
http://www.ietf.org/rfc/rfc2822.txt?number=2822
検索したら日本語もどっかにあるよ。たぶん。

824 :デフォルトの名無しさん:03/08/21 11:59
あまりにも出来レースで、自演の可能性すら疑ってしまうな

825 :デフォルトの名無しさん:03/08/21 12:08
いや822とか狙ったとかわけわからん

いいからさっさと教えやがってくdさい

826 :デフォルトの名無しさん:03/08/21 12:10
↓「EXTERIOR GATEWAY PROTOCOLについて教えてください」

827 :デフォルトの名無しさん:03/08/21 12:14
↑ググれ

828 :デフォルトの名無しさん:03/08/21 12:47
>>827
お前が質問しろ。RFC827

829 :デフォルトの名無しさん:03/08/21 13:12
>>828
お前は失恋しろっ!

830 :デフォルトの名無しさん:03/08/21 13:50
ネプロスレかと思ってたが、ジョジョスレの雰囲気

831 :デフォルトの名無しさん:03/08/21 13:52
悲しけりゃここでお泣きよ 穴ふさぐパッチもあるし
ワームがこわした君のPCを やさしく直すワームもある

832 :デフォルトの名無しさん:03/08/21 16:01
>>831
ナツカシワロタ

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)