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

ネットワークプログラ ..

301:デフォルトの名無しさん
07/10/25 06:54:40
ソケットを接続待ちの状態にするためにlistenは必要。
第二引数は最大コネクション数ではなくて、キューの数だった気がする・・・
要は一気に接続要求が来たときに待ってもらう数な。

302:デフォルトの名無しさん
07/10/25 10:23:58
データを送信した時に全データが送られないってことがあるじゃないですか。

これを明示的に起こさせる、起こしやすくするには、どうしたらいいですか？
どんな設定をしたらいいですかね？

setsockoption関数？で送信バッファを1に変えても変化なかったんですよね･･･

全データ遅れなかった時の動作が確認できないんです･･･

303:デフォルトの名無しさん
07/10/25 11:47:12
>>300
listen　で実際にサーバのポートを開く。
socket　->　bind　->　connect　っていう手順もありうるので、bind　だけではまだポートが開いてない。

304:デフォルトの名無しさん
07/10/25 11:50:48
>>302
受信側の受信バッファも小さくしてみたら？
あと、受信側が　recv　しなければ、そのうちバッファが一杯になって送れなくなる。
1秒に1バイトずつちまちま　recv　するようにしてみるとか、どうかな。

305:デフォルトの名無しさん
07/10/25 11:52:46
>>304
回答ありがとうございます

ちょうど今自己解決しました

送信データを1バイトずつSendしたらなりました

306:デフォルトの名無しさん
07/10/25 15:37:11
nagleを切ればいいだろ

307:デフォルトの名無しさん
07/10/25 21:17:23
>>306
やっぱり、全然無理でした。
どうやったらできるんだろ？
カーネルの送信バッファとsetsockoptで設定するバッファって同じことを指してるんでしょ？

送信バッファ 30バイト、送信データ100バイトとした時
send関数を使うと、戻り値が30と返ってくるって思ってるんだけど間違ってる？

308:デフォルトの名無しさん
07/10/25 21:19:18
ちなみに
サーバをIOCPで実装しています。WSASend, WSARecvを実行しています

309:デフォルトの名無しさん
07/10/25 21:19:54
だから正確にはsend関数は使ってません

310:デフォルトの名無しさん
07/10/25 23:37:18
TCPのチェックサムって計算

仮想ヘッダ+TCPヘッダ＋ペイロードだよね？

仮想ヘッダとTCPヘッダはいいけど
ペイロードってどこまでなの？

HTTPとかTCPの下になんかプロトコル付く場合
だけ計算みする

311:デフォルトの名無しさん
07/10/25 23:45:01
>>310
> ペイロードってどこまでなの？

全部（もしデータが奇数だったら１バイトの0x00を付加)

312:デフォルトの名無しさん
07/10/26 03:14:59
>>307
TCP/IP の下の NDIS （パケットドライバ）あたりが、パケットの非同期送信を
また別んとこのメモリの許す限りキューイングしてくれるから、そこいらへんは
あんまりあてにならない。

313:デフォルトの名無しさん
07/11/02 15:00:24
winsockでTCPでプログラミングをしているのですが、
たまに接続が上手くいかない時があります。
connect()を実行しても、タイムアウトになってしまいます。
一度プログラムを終了して、再度connect()したら普通に接続できます。
上手く行く時とそうでない時があるのですが、どのような事が原因として考えられるでしょうか？

314:デフォルトの名無しさん
07/11/02 15:07:17
たまたまサーバや回線が混雑してて繋がらなかったとかじゃないか
WSAGetLastErrorでエラーの詳細を確認しる

315:デフォルトの名無しさん
07/11/02 15:16:06
>>314
connect()のエラーは10060でした。
多分タイムアウトだと思うのですが・・・。

while(SOKET_ERROR){
　　connect();
}

のような感じにしていて、常に10060が返って来ます。
ネットは色んなHPを見て回れるので混雑してるとかではないと思います。
↑のループをずっと繰り返している間に、新しくクライアントのプログラムを作ってサーバに接続を試みたところ、
普通に接続が出来たので、サーバが原因ではない事は分かってます。

316:デフォルトの名無しさん
07/11/02 15:31:53
connectに失敗した場合、closesocketをして、再度ソケットを作成、サーバのアドレスの設定等を行い、
その後またconnect()を実行する事で、サーバに接続する事は出来ました。
しかし最初にconnect()に失敗する前のsocket()関数は正常に終了しており、sockaddr_in構造体の設定も間違ってません。
connect()が失敗した際に行う再設定は、全く同じ内容のものなのですが・・・

一体何が原因なのでしょうか・・・。

317:デフォルトの名無しさん
07/11/02 15:43:53
URLﾘﾝｸ(videointroplayer.web.fc2.com)

318:デフォルトの名無しさん
07/11/03 14:28:53
サーバは何？誰がどうやって作ったもの？

319:デフォルトの名無しさん
07/11/03 18:07:41
サーバは自分で作りました。これもC、Winsockで作ってます。

320:デフォルトの名無しさん
07/11/03 19:35:35
>>316
connectのエラーコードは何だよ。それくらい書けばいいのに。

321:デフォルトの名無しさん
07/11/03 19:50:06
>>320
>>315

322:デフォルトの名無しさん
07/11/03 19:59:43
>> 316
九割九分九厘名無氏作蟲

323:デフォルトの名無しさん
07/11/03 20:09:08
>>316
タイムアウトだから、>>314が言っているような感じなんじゃね？
起きている事象として把握できているのが、10060だけだと考えるのはキツイかも。

回線の種別（loopback、外部への接続）とか、connectの頻度とか、
connectがエラーになる接続先は常に同一なのかとか、その辺はどうなのだろう？
あと、クライアントとサーバと両方を自分で作っているのなら、connectと
acceptの数や時刻をログ出力して比較してみるとか。
いくつか考えうる要因をピックアップして調べてみては？

324:デフォルトの名無しさん
07/11/03 20:25:01
>>323
しかし、connect()に失敗したら再度connect()を実行するような設計にしています。
回線の混雑が理由だったら、いつかは接続できそうな気が・・・。実際はこの状態になるといつまでも10060を返し続けます。
また、10060を返してる間に、他のクライアントプログラムを実行しサーバの同じポートにconnect()を実行したら普通に接続できました。
もちろん同じPCからです。また、10060を返した後にソケット破棄⇒再生成してconnect()を実行すると接続できるので、
どうもネットワークの混雑という理由は考えにくいような気がします。とはいえ、ネットワークの問題は原因が特定しにくいので、
完全にそうではないとは言い切れないです。

connectの頻度はそう多くないのですが、まずサーバに接続し、その直後にもう一つ接続を作ります。
この2つ目の接続でconnect()エラーが発生します。2つ目の接続はファイルの送受信用のソケットで、スレッドを立ててそちらで処理しています。
なのでacceptとconnectの数は2回ですね。

325:デフォルトの名無しさん
07/11/03 20:40:58
もしかして、connect()を短い間隔で2回やってるのが原因なのかなと思って、
2回目のconnect()をする前にSleep(200)を挟んで何度か実行したところ、
connect()でのエラーはなくなったように思えます。（まだ試行回数が多くないので分からないですが）

短い時間で連続してconnect()を実行した場合、何が起こるんですかね・・・？

326:デフォルトの名無しさん
07/11/03 21:14:09
2MSL だろ

327:デフォルトの名無しさん
07/11/03 21:19:35
サーバのOSはWinXP ProとかHomeだったりするのかい

328:デフォルトの名無しさん
07/11/03 21:24:36
>>325
ファイアウォールのログは確認しておいてね。

329:デフォルトの名無しさん
07/11/03 22:26:00
>>326
winsockの仕様というよりも、TCPの仕様ですか・・・。
でも通信をクローズしてないのに関係あるんですかね？
全然詳しくないので何ともいえないですが・・・

>>327
OSはWinXP HomeEdition ver.2002 SP2です。

>>328
火壁のログの確認・・・ググってきます

330:デフォルトの名無しさん
07/11/03 22:37:40
>>324
まずは、ネットワークトレースを見てからだ。
10060なら、syn、syn-ackがどうなっているか確かめようぜ。

331:デフォルトの名無しさん
07/11/03 22:45:35
Linux使いなのでコード等よくわからんが、
ネットワークプログラミングのデバッグならパケットキャプチャだ。
WindowsならWiresharkがあるはず

332:デフォルトの名無しさん
07/11/03 22:54:04
Wiresharkだったらこの間入れたはず。
でも、英語だらけで使い方がよく分からずに放置した記憶が・・・！

syn、ackってTCPの3wayHandshakeとかの話ですよね？
そんなところまで見れるとはなんと便利なソフトなのだろうか。
とりあえず使い方から調べなおしてちゃんと根本から問題解決するか・・・

333:デフォルトの名無しさん
07/11/03 23:15:51
333ゲット

334:デフォルトの名無しさん
07/11/03 23:22:26
ところでみなさんGUIのネットワークプログラムを作るときは
非同期ソケットでスレッド1本派
同期ソケットでマルチスレッド派
のどっちですか？

335:デフォルトの名無しさん
07/11/03 23:34:09
なんとかパケットキャプチャは出来たけど、実際見てもよく分からないという現実！
URLﾘﾝｸ(kjm.kir.jp)
No.10-12が多分最初の接続ですね。その後のポート5000がファイル送受信用の接続です。
ポート番号については突っ込まないで下さい＞＜

最後の方で色々とsynとackを送りまくってますが、ここら辺がソケット破棄して再設定してconnect()してるあたりですかね・・・。
俺の知識じゃ、これ見て　でっていう　レベルなんですが・・・

336:デフォルトの名無しさん
07/11/03 23:41:58
よくわからんがNo.30とNo.50の 192.168.0.185:3739 -> 192.168.0.186:5000
に185が応答していないように見えるが。

ファイル送受信用、と言われても・・・そんなの話に出てきてないから・・・

337:デフォルトの名無しさん
07/11/04 00:01:32
XP Homeはサーバ用途が制限されていたような

338:デフォルトの名無しさん
07/11/04 00:01:49
>>336
>>324で一応書いたつもりでしたが、ちょっとゴチャゴチャして見にくかったですねm(_ _)m

多分34、50、63のSYNを送ってサーバからの応答がないままタイムアウトになって、
ソケット破棄、ソケットの再生成と再設定⇒connect()が67で、その後の応答とかが68、69で
接続が確立してるっぽいですね。それ以降のものはファイル送受信のパケットだと思います。

見る限り、サーバからのACKが返ってこないようですが、クライアントからのSYNは送られてるんですよね。。。
サーバにそれが届いてないか、サーバに届いてるけど、サーバが送り返してくるSYN,ACKが途中でパケットロスしてるのか・・・。

339:デフォルトの名無しさん
07/11/04 00:11:49
>>338
ポート5000からの応答が無いな。そっちを調べるしかないだろ。

340:デフォルトの名無しさん
07/11/04 00:13:42
>>335
ポート5000ってのはﾅﾝﾀﾞﾖ。サーバー側のプログラムが悪いんじゃないのか。

341:デフォルトの名無しさん
07/11/04 00:29:10
>>340
ん、どういう事ですか？あまり49151以下の予約済みポートは使わない方がいいって事ですか？
とりあえずサーバ側のプログラムを再度見直してみます。

342:デフォルトの名無しさん
07/11/04 00:34:25
>>334
ケースバイケースだろ。

343:デフォルトの名無しさん
07/11/04 01:49:58
netlinkの使い方を日本語で詳しく説明してるサイトないかな？
Manpage of NETLINK以外で

344:デフォルトの名無しさん
07/11/04 06:18:34
サーバ側が、50000番の接続要求に反応しない理由を調べたほうがいい。

1.サーバ上で、50000番への接続受付が満杯
2.サーバ上で、50000番がまだ再利用可能ではない(サーバ上で、netstatして50000番の状態を調べれ)
4.サーバが再起動した
3.パケットロスが発生してる(ローカルネットワークじゃ考えにくいと思う)

1,2,3,4の順で可能性は高いと思う

345:323＆328
07/11/04 07:14:35
>>341
ファイアウォールのログは見てみた？
SYN floodか何かに判定されてコネクション要求がファイアウォールで破棄されていないかな、
と思ったんだが。

…もしかして、俺、考えている方向ずれてる？　そうだとしたら、すまん。

クライアントとサーバのプログラムにログ出力を付け加えて、コネクションの確立の
様子を見るのもあり。connectやacceptの前後といった場所に、printf()で良いから
付け加えて、クライアントとサーバの両方の処理がどのように、どこまで出来ているのか
確認するってことで。

346:デフォルトの名無しさん
07/11/04 07:56:09
URLﾘﾝｸ(youtubetv.atspace.com)

347:デフォルトの名無しさん
07/11/04 09:14:42
FreeBSD上でプログラムを組んでいて不思議な事に出くわしたので相談します。
IPアドレスを入力し、そのアドレスのネットマスクを取得するプログラムを組んでいますが、
ICMP_MASKREQを使って取得しています。しかし、AlliedTelesisのL3スイッチではきちんとICMP_MASKREPLY
が返ってくるのに、CISCOのルータやPCだと応答がまったく返ってきません。
これはプログラムミスか、単にCISCOのルータがRFCに準拠していないのか・・・
どうでしょうか？意見をお願いします。

348:デフォルトの名無しさん
07/11/04 10:52:27
>>347
> CISCOのルータ
Firewallで捨てられてるとか？　ルーターのicmpカウンタをチェック。　

> PCだと
ホストは必ずしも答える義務無し。

349:デフォルトの名無しさん
07/11/04 11:22:08
>>348
ヒントありがとうございます、CISCOルータにて、ip mask-reply コマンドでMASKREPLY
を有効にしたところ期待通りにプログラムが動きました、デフォルトでno ip mask-reply
になっているようです。

PCでは答える義務無しですか、残念。
SNMP以外でネットマスクを取得する手段を考えていたのですが・・・
考え直してきます。

350:デフォルトの名無しさん
07/11/04 11:48:20
>>349
> SNMP以外でネットマスクを取得する手段

MASKREQUESTって聞いているホストが使うべきマスクを問い合わせるのに
使うのでしょう？　問い合わされたホストのマスクを返すのではなくて。
昨今はDHCPで取得される情報なのでほとんど使われない機能。

351:デフォルトの名無しさん
07/11/04 11:52:28
RFC1812はデフォルトで答える事をMUSTにしてるので、お前が設定したのだろう。

352:デフォルトの名無しさん
07/11/04 12:23:40
すれ違いで申し訳ないんですが、
googleでXXXを検索。

のように、webページに引数を渡す？みたいな事ってどうやればうまく
できますか？

353:デフォルトの名無しさん
07/11/04 12:34:23
>>350
勘違いしていました、指摘ありがとうございます。
たしかにそうですね・・・、実験で確認がとれました。
MASKREQUESTで問い合わせたアドレスのネットマスクを取得する考えは根本から間違ってました。

>>351
ルータ初期化して試してみましたが、デフォルトでno ip masu-replyになってました。

354:デフォルトの名無しさん
07/11/04 12:37:34
ヒント：URI、クエリ、GET要求

355:デフォルトの名無しさん
07/11/04 13:53:11
>>354
ヒントありがとうございます！
大変助かりました！

356:デフォルトの名無しさん
07/11/04 14:15:27
>>353
iosのバージョンとかにもよるんじゃないの。
デフォルトのイメージが書き換えられてる場合もあるし。

357:デフォルトの名無しさん
07/11/04 14:16:09
おまいら、IOSとかCiscoの製品使える？
やっぱネットワーク系のプログラム組んでる人間としてCCNAぐらい取っておくべきかな？

358:デフォルトの名無しさん
07/11/04 14:19:54
そんな暇あったら、カマー本やスティーブンス本読破すれば?
基本的な知識あれば、ルータ設定くらい簡単だよ。

359:デフォルトの名無しさん
07/11/04 14:46:40
自分の力に自信が無くて
資格を求めてるんだろ。
取るのを勧めてやるのが優しさだよ。

もっとも俺ならプログラムなんてもう辞めろと言うけどね。

360:デフォルトの名無しさん
07/11/04 20:27:40
>>351
RFC1812が書かれた当時とは実情が変わるなんて良くあること。

ciscoのマニュアルによると。

ip mask-reply

　To have the Cisco IOS software respond to Internet Control Message 　
　Protocol (ICMP) mask requests by sending ICMP mask reply messages, use
　 the ip mask-reply command in interface configuration mode. To disable
　 this function, use the no form of this command.

Defaults

　Disabled　<<<<<<

コマンドが導入されたのはIOS 10.0。

361:デフォルトの名無しさん
07/11/05 22:27:16
プログラマからみたIOSっていうとXMLみたいなもんだからなぁ

362:デフォルトの名無しさん
07/11/06 18:17:05
全然違うぞw

363:デフォルトの名無しさん
07/11/10 13:29:28
IPv4かIPv6かわからないときgetaddrinfoを利用し調べる方法が
Wikipedia項目ﾘﾝｸの下のほうに書いてありました

Windowsではws2tcpip.hに宣言がありました
getaddrinfoへ渡したaddrinfoのai_addrを利用し、IPv4かIPv6のアドレスを取得すると思われるのですが
ai_addrの型はsockaddrでその定義はwinsock2.hにしかなくそれは以下のようになっていました
struct sockaddr {
　u_short sa_family; 　　　　　　　/* address family */
　char　sa_data[14]; 　　　　　　/* up to 14 bytes of direct address */
};

これだと8*14==112で、IPv6アドレスを表すための１28bitに足りないような気がするのですが思い違いでしょうか?

364:デフォルトの名無しさん
07/11/10 13:37:49
sockaddr_in6にキャストしてつかうんじゃね?

365:デフォルトの名無しさん
07/11/10 13:41:07
sockaddr sockaddr_in sockaddr_in6
でググれ

366:デフォルトの名無しさん
07/11/10 13:44:34
FTPの同時接続数とレスポンスをまとめたサイト知ってる方います？
並列は３回線くらいがいいのかな・・・

367:デフォルトの名無しさん
07/11/10 15:40:26
環境によって違う。

>>363
もっとCの勉強した方がいい。

368:デフォルトの名無しさん
07/11/10 18:09:19
計算もできない馬鹿がいるって
聞いて飛んできました

どこどこ？

u_shortが8bitってどんな頭してるんだよw
染んでこいよw

369:デフォルトの名無しさん
07/11/10 18:12:03
>>368
顔から火を噴きながらとんでけ

370:デフォルトの名無しさん
07/11/10 18:30:01
氏ねとは言い過ぎだが
レベルの低いやつは質問しない
されても無視するようにしないか？

371:デフォルトの名無しさん
07/11/10 19:57:12
さすがに今ではshortが8bitってことはほとんど無いが・・・
逆に16bitであり続ける理由も無いな

372:デフォルトの名無しさん
07/11/10 20:00:28
そう考えると結構恐ろしいんだよな
プロトコルにつかう構造体はバイト単位じゃなくて
オクテット単位か出来ればビット単位で定義すべきなんだよな

373:デフォルトの名無しさん
07/11/10 20:09:49
Cには2進表記すらない。
0b1_01110_00

374:デフォルトの名無しさん
07/11/10 20:10:40
>>371
殆どない、じゃなくて、規格上ありえませんが。
16bitより大きい可能性はあるけど。

375:デフォルトの名無しさん
07/11/10 20:14:32
現実を知らず
教科書しか読まない奴は
レスしない方がいいよ。

376:デフォルトの名無しさん
07/11/10 20:16:45
>>375
アホ表明ですか。毎度ご苦労様です。

377:375
07/11/10 20:18:34
>>376
俺はあほじゃねーよ
落ちこぼれなだけだ糞が

378:デフォルトの名無しさん
07/11/10 20:31:08
せめてageたら？（藁

379:デフォルトの名無しさん
07/11/10 21:10:59
>>374
いやいや、あるよ。規格上でも char≦short≦long なだけだし。
intに至ってはもっとひどい

380:デフォルトの名無しさん
07/11/10 21:14:39
規格ではshortは-32767～+32767を保証してなかったっけ？

381:デフォルトの名無しさん
07/11/10 21:20:41
>>380
ISO/IEC 9899によるとちゃんとその規定があるな

つか規格読んでもshort intとshortの区別がつかねぇ・・・
longとlong intの違いって何？
long long ago; ってそういうギャグを実現したかっただけ？

382:デフォルトの名無しさん
07/11/10 21:30:51
>>379
バカまるだし
shortは16bit以上、longは32bit以上が必須

383:デフォルトの名無しさん
07/11/10 21:37:59 BE:1262592386-2BP(250)
どの規格のC？
てかCじゃなくてC++？

384:デフォルトの名無しさん
07/11/10 21:40:46
5.2.4.2.1 Sizes of integer types <limits.h>
も読んだことない奴は黙ってろよ、ボケが。

URLﾘﾝｸ(www.jisc.go.jp) で X3010 な。

385:デフォルトの名無しさん
07/11/10 21:40:44
>>382
＞longは32bit以上が必須
さすがにこの嘘はオレでも見抜く

386:デフォルトの名無しさん
07/11/10 21:43:06
ずっと384のターン

387:デフォルトの名無しさん
07/11/10 21:54:57
知らないことは恥ではないし、バカにされる理由もない。
誰もが最初は知らないんだし、少なくとも俺は知らないという理由ではバカにしない。

恥なのは、知らないくせに知ったかぶって間違いをさらすこと。
嘘を言いふらして、周りにも迷惑をかけるし。

388:デフォルトの名無しさん
07/11/10 21:56:24
C89より昔のCプログラムはネットにつなぐな氏ねってことですかそうですか

389:デフォルトの名無しさん
07/11/10 21:57:45
もし>>379と>>385(と>>371)が別人だったら笑える。
こんなにも恥さらしが何人も居るとは。

390:デフォルトの名無しさん
07/11/10 21:58:21
>>387
あんまり384をいじめるなよ

391:デフォルトの名無しさん
07/11/10 22:01:41
もしかして、>>387と>>384が同一人物だと思っているのですか？

392:デフォルトの名無しさん
07/11/10 22:03:37
>>388
発端となった>>371は、「今では」と言っているので、昔の話は関係ありませんね。
「今のCの規格」で、shortのサイズが決まっているかどうかですよ。

393:デフォルトの名無しさん
07/11/10 22:08:30
　

394:デフォルトの名無しさん
07/11/10 22:09:21
>>392
昔の規格が使用禁止になったわけじゃないしなぁ。
ていうか、使用禁止にしてほしい。マジで。頼むよ。

395:デフォルトの名無しさん
07/11/10 22:14:06
新規格を出せば後は野となれ山となれ

396:デフォルトの名無しさん
07/11/10 22:16:54
ふと思ったんだけど、C99ってみんなもう適用してる？

397:デフォルトの名無しさん
07/11/10 22:19:03
もう適用してる？
(ﾟДﾟ)ﾊｧ?

398:デフォルトの名無しさん
07/11/10 22:26:57
>>397
冷静に考えたら適用って変な言い方かも。
つーか -std=c99つけるとコンパイル通らないコードとか
けっこう多くてさー

399:デフォルトの名無しさん
07/11/10 22:33:08 BE:946944094-2BP(250)
K&R2版のANSI Cに従って書いてる。

つもり

400:デフォルトの名無しさん
07/11/10 22:36:04
結局、 shortが16bitとは言い切れない時代の規格が
まだまだゾンビのように蔓延ってるってことか・・・やりきれんな

401:デフォルトの名無しさん
07/11/10 22:40:10
そんなの<limits.h>やsizeof使えば簡単に弾けるじゃん。

402:デフォルトの名無しさん
07/11/10 22:43:14
>>401
で？

403:デフォルトの名無しさん
07/11/10 22:43:29
>>401
弾いてどうすんだよwww コンパイル通らないだろwww
そんなリファクタする暇と金は貰ってねーよwww ｻｰｾﾝwww

という人が多いというかほとんどだと思う。

404:デフォルトの名無しさん
07/11/10 22:46:13
弾いたら動かないだろｗ

405:デフォルトの名無しさん
07/11/10 22:49:50
>>400のケースは新しく書いたコードをコンパイルするんでしょ？
希少な環境向けのコードは、必要に迫られてから実装すればいいのでは？
コンパイルの失敗を安全弁にしといて。

406:デフォルトの名無しさん
07/11/10 22:53:12
>>405
いや、無理だな
コンパイルが通ってしまって挙動が変わるのが怖すぎる
古ければ古いほどなおさら・・・ｲｧｲｧ

407:デフォルトの名無しさん
07/11/10 23:14:48
#ifndef __STDC__
#error ばーか
#endif

つーか、まず「C89以前のコンパイラしかない環境」は無いし(GCC等のクロスも含めて)
例え「C89以前」だとしても、「それに加えてshortが16bit未満」なんてこと、ありえないよ。
世界中捜せば、pccを自分でコンパイルして常用している人くらいは居るかもしれないけどさ。

408:デフォルトの名無しさん
07/11/10 23:18:00
そもそも、C89、いわゆるANSI-Cだって
プロトタイプやconst,voidなんかを導入したとはいえ、
「出来るだけそれ以前の処理系が規格違反にならないような規格」として作られたんだから。
intのサイズとか。

409:デフォルトの名無しさん
07/11/10 23:19:48
>>407
「C89以前のコンパイラしか使わせてもらえない職場環境」
は実在します

410:デフォルトの名無しさん
07/11/10 23:23:13
12bitのDSPが御座いまして

411:デフォルトの名無しさん
07/11/10 23:25:15
H8Sとか普通に使うんすけど

412:デフォルトの名無しさん
07/11/10 23:42:45
へー、みんな、そんなにshortが16bitに満たない環境を使ってるんだー
すごいねー

413:デフォルトの名無しさん
07/11/10 23:47:12
ここはネットワークプログラミング相談室
いつからC言語信者が語り合うスレに・・・

414:デフォルトの名無しさん
07/11/11 02:30:05
407は自宅警備員？

415:デフォルトの名無しさん
07/11/11 02:33:28
うん

416:デフォルトの名無しさん
07/11/11 04:06:51
>>407
＞「それに加えてshortが16bit未満」なんてこと、ありえないよ。
そういう世界に生まれたかった

417:デフォルトの名無しさん
07/11/11 04:17:13
今からでも遅くはないZE

っ脳内世界

418:デフォルトの名無しさん
07/11/11 12:05:04
とりあえずシロートは↓嫁
URLﾘﾝｸ(www9.plala.or.jp)

419:デフォルトの名無しさん
07/11/11 12:19:25
已学了的「long」修尺寸。
其「long」用略了「long int」的述，
那个意成「与int型同比那个大」。
在同里(上)表示「与int型同比那个
小的」「short」(short int 的省略)也存在。
ANSI C short 和 long 的字幅度被
理器托付，象只以下一地定着。

420:デフォルトの名無しさん
07/11/11 13:57:54
>>418
そのページの作者↓のページで扱える数値の範囲に嘘を書いているから信憑性ゼロ
URLﾘﾝｸ(www9.plala.or.jp)
× -32768～32767
○ -32767～32767

421:デフォルトの名無しさん
07/11/11 14:03:33
つーか>>384を読んでくれよ。
ここの部分は馬鹿でも理解できる記述になってるから。

422:デフォルトの名無しさん
07/11/11 14:07:49
>>420
お前それは本気で言ってるのか…(ﾟдﾟ)

423:デフォルトの名無しさん
07/11/11 14:13:04
>>384でFA！
あとはC言語スレで！

424:デフォルトの名無しさん
07/11/11 14:26:26
ほんとこういうくだらない話題のときだけは伸びるな

425:デフォルトの名無しさん
07/11/11 17:52:14
>>421
X3010ってC99のことじゃないの？

426:デフォルトの名無しさん
07/11/11 17:57:47
いやX3010のうちX3010:2003がC99相当

427:デフォルトの名無しさん
07/11/11 18:18:53
>>426
なるほど

428:デフォルトの名無しさん
07/11/11 18:20:21
intのサイズはどうでもいいというか決まってないよね？

429:デフォルトの名無しさん
07/11/12 10:02:48
AcceptExの完了をGetQueuedCompletionStatusで捕捉できない・・・
その次のクライアントからの送信はGetQueuedCompletionStatusで捕捉できるのですが
第4引数のLPOVERLAPPEDはAcceptExに渡したのがきます。　＞＜

期待したのは
メインスレッドでAcceptExを呼ぶ -> クライアントがconnectしてくる ->
　　　ワーカースレッドで呼ばれてたGetQueuedCompletionStatusが処理を返す -> クライアントが"Hello"と送る -> ワーカースレッドで呼ばれてた(ry
という感じなのですが

実際は
メインスレッドでAcceptExを呼ぶ -> クライアントがconnectしてくる ->
　　　まだGetQueuedCompletionStatusから返らず＠ワーカースレッド -> クライアントが"Hello"と送る -> ここで初めてGetQueuedCompletionStatusが処理を返す
となってしまします。
初めてGetQueuedCompletionStatusが返ったときのOVERLAPPED::InternalHighは5となっておりクライアントからの送信に反応したものと思われます。

AcceptExの完了を捕捉しないのが仕様かと思ったのですが
URLﾘﾝｸ(www.codeproject.com)のコードを見てみるとワーカースレッド内にswitch文内をみるとsend、recvのみならずacceptも捕捉できることを
前提として書かれてるように見えます。　しかし実際コンパイルして実行してみるとやはり上記とおなじことになってしまいました。

430:デフォルトの名無しさん
07/11/12 13:13:54
いや仕様だし。

431:デフォルトの名無しさん
07/11/12 13:52:02
>>429
MSDN読んだら。
データを受け取るまで待ちたくないのなら、
dwReceiveDataLengthに0を渡すと良さげ。

432:429
07/11/12 16:22:13
>>431
おおおおおお　ありがとうございます
dwReceiveDataLengthに0を指定し期待していた動作を得られました
MSDNのdwReceiveDataLengthの説明のところにもろに書いてありました不覚orz

433:デフォルトの名無しさん
07/11/12 22:14:33
VB.netのUDPの使用について質問があります。
2台のコンピュータ間で互いに自身の画面をキャプチャして相手に送るソフトを作っています。
それを送信して、受け取り、見ることはできるようになったのですが、外部ネットワークとの通信ではうまくいきません。

恐らく、データの重さから途中でパケットが消えているのだと思うのですが…。
流石に現段階よりもさらにデータを少なくすると、とても見れたモノではないので、
パケット分割をして送信しようと思うのですが分割方法がわかりません。
※ローカルネットワークではできています。

送信はキャプチャ画像を一旦メモリーに保存し、それをbyte配列に直して送信しています。

TCPは通信する相手との問題で採用する気はありません。
もし、出来ている時点までのソフトウェアのソースコードが必要なら自サイトにアップロードしダウンロードできる状態にします。

開発環境はVB2005、通信相手とはUDPを使用した単純な文字列のみのチャットなら出来ています。
よろしくお願いします。

434:デフォルトの名無しさん
07/11/12 23:02:36
>>433
うるせえボケTCPでやれ

435:デフォルトの名無しさん
07/11/12 23:10:59
UDPでやっていちいち検証するくらいならTCPの方がいい

436:デフォルトの名無しさん
07/11/13 00:59:48
それかRTPを使え。

437:デフォルトの名無しさん
07/11/13 09:17:27
>433
ホールパンチングが必要ならTCPで外にサーバを立てろ。
遅延の問題ならTCPで多重化しろ。
単にFAQ読んでないだけだろ？

438:デフォルトの名無しさん
07/11/13 11:17:41
>>363
WindowsでのIPv6プログラミング講座　第１回
URLﾘﾝｸ(www.ipv6style.jp)
URLﾘﾝｸ(www.ipv6style.jp)

439:デフォルトの名無しさん
07/11/13 16:12:57
>>434-437
返信ありがとうございます。

パケットの分割でなんとかなるかと思いましたが、思いのほか他の方法でする回答が多かったので、一から仕様を変更しようと思います。
ありがとうございました。

440:デフォルトの名無しさん
07/11/13 17:20:23
FTPでQUIT発行してbyeした時に、通常なら受信したバイト数とかの情報を返してくるんだけど、
返って来ない場合があります。どう直せばよいのでしょうか？

221-You have transferred 0 bytes in 0 files
221-Total traffic for this session was 834 bytes in 0 transfers.
221-Thank you for using the FTP service on ftp4.geo.bbt.yahoo.co.jp.
221 Goodbye.

441:デフォルトの名無しさん
07/11/13 17:25:40
なぜここに？

442:デフォルトの名無しさん
07/11/13 21:15:47
URLﾘﾝｸ(tool-6.net)
Apache2で実行すると
400 Bad Rqest Errorが出るんですが、原因がわかりません。
なぜなんですかね？

443:デフォルトの名無しさん
07/11/13 22:40:45
HTTP1.0にしたらうまく動作したんですが、1.1ではなぜ出来ないんですかね？

444:デフォルトの名無しさん
07/11/13 22:46:49
Host情報送って無いんじゃね？

445:デフォルトの名無しさん
07/11/13 23:24:51
Host情報を送る際のコードが載っているサイトとかないですかね？

446:デフォルトの名無しさん
07/11/13 23:30:39
新宿２丁目と

447:デフォルトの名無しさん
07/11/13 23:39:12
歌舞伎町

448:デフォルトの名無しさん
07/11/13 23:41:03
郵便局

449:デフォルトの名無しさん
07/11/14 00:18:05
自力で調べろや坊主
って事ですか？

450:デフォルトの名無しさん
07/11/14 00:35:54
windumpでパケット調べろ。

451:デフォルトの名無しさん
07/11/15 19:10:35
GetTCPTableとかで取得したTCPコネクションを切断するにはどうすればいいんですかね？

452:デフォルトの名無しさん
07/11/15 21:09:01
HTTP1.1での通信方法がのっているサイトありましたら教えて頂けませんか？

453:デフォルトの名無しさん
07/11/15 21:42:30
Host情報を送ってHTTP1.1で通信するのは何も難しいことじゃないが今は1.0でええじゃないか
きっとおまえさんにゃまだ早いんだよ

454:デフォルトの名無しさん
07/11/16 03:06:54
RFCも読まずにHTTPをしゃべろうという人を困らせるために、
サーバはPOSTに対してできるだけ 100 Continue を返すべき。
何かと思ってちゃんと調べるだろうから。

455:デフォルトの名無しさん
07/11/16 03:20:59
>>452
URLﾘﾝｸ(ftp.rfc-editor.org)

分かりやすい日本語サイトなら
URLﾘﾝｸ(www.studyinghttp.net)
とか・・・

456:デフォルトの名無しさん
07/11/16 03:25:26
>>454
いや、いっそのことRFCそのものを返したらどうだろう？

457:デフォルトの名無しさん
07/11/16 03:52:54
でもHTTPとかContent Length義務にしてくれたほうがいいよなー

もし最初の200バイトだけ送信して何もレスポンスがないまま5分たってから
残りを送信する仕様の（糞）サーバがあったとして、
Content Lengthが義務だったら待ちつづけるし。。。

あといきなりデータ送信終了してもcloseかけてくれない（糞）サーバがあったとしたら、
データがいつ終わったのか分からないし。。。

458:デフォルトの名無しさん
07/11/16 04:34:14
>>457
それどちらも Content length の有無と関係ないですよ。

459:デフォルトの名無しさん
07/11/16 04:47:06
いや例えば後者の場合、サーバがデータ送信終了してもクライアントでrecvの戻り値が0になるなり
なんなりしなきゃ終わったかどうか分からなくないですか？
Content-lengthあればrecvの戻り値が0であろうがなかろうがそこで自信を持って切れますし。。

460:デフォルトの名無しさん
07/11/16 04:59:36
>>459
えーとつまり「RFC違反だけど content length だけは正常に返す」という
サーバを救済できるから、content length を RFC で義務化すべき、
ということですか？

レスポンス開始時にはサイズが分からないので Connection: Close で返す、
というまともなサーバを実装不可能にしてまでやる意味があることとは、
あんまり思えないです。

461:デフォルトの名無しさん
07/11/16 05:06:06
そうだなレスポンス開始時にサイズが分からないこともあるか。
ｽﾏﾝｶｯﾀ
でもRTSPとかはContent Length義務だよね。
そうしないとデータ境界わけわかんなくなるし。
こっちのほうがクライアント側がやりやすかったんで
言ってみただけだわ。

462:デフォルトの名無しさん
07/11/16 05:14:00
なんのためのチャンクだ

463:デフォルトの名無しさん
07/11/16 06:09:06
>>461
アホですね。

464:デフォルトの名無しさん
07/11/16 12:02:36
>>462
チャンクってRTSPにもHTTPにもないだろ？

465:デフォルトの名無しさん
07/11/16 12:20:06
TCP/IPソケット通信で質問します。
一度connectしたら常時接続のままという使い方をしてるんですが、
通常サーバ　－　クライアントどちらかでソケットcloseすると切断を検出出来ると思うんですが、
相手がcloseしないでリブートなどを行うと切断検出できません（無効となったソケットを維持）

プログラムから一定間隔でping通信する
１通信毎にセッションを閉じる（頻繁に通信が発生するのであまりやりたくない）
空の電文を常時やり取りして生存を確認する

もっとほかに断検出する良い方法があったら教えて下さい

466:デフォルトの名無しさん
07/11/16 12:41:39
>>465
TCPはそういうもの。
途中のルータが落っこちても一緒。
TCPとしては検出する仕組みをもっていない。
アプリで検出したくなければ、KeepAliveするぐらいかな。

467:デフォルトの名無しさん
07/11/16 12:59:25
>>464
＞チャンクってRTSPにもHTTPにもないだろ？

はぁ？

468:デフォルトの名無しさん
07/11/16 13:03:34
>>465
> 空の電文を常時やり取りして生存を確認する

TCPはデータストリームなので、空のパケットは送れません。

1. データストリームの中のデータを型付けして、
通常データ以外に、alive check用パケットも送れるようにする。
2. keepalive socket optionを使う。(詳しくはFAQを>>1)

1.はICMP pingと違って、hostの死活でなく、
peerの死活を調べられるという利点があります。

>>466
「TCPが」というか分散環境ってそういうものだしね。
単純に落ちるfailure以外に、Content-Length: が違うなど、
mal-functional failureだって起りうる。

469:デフォルトの名無しさん
07/11/16 13:05:11
>>464
ハイパーテキスト転送プロトコル -- HTTP/1.1
3.6.1 チャンク形式転送コーディング
URLﾘﾝｸ(www.studyinghttp.net)

470:467
07/11/16 13:08:15
まあchunkedなんてあんま使われてないけどな

自分で使うことはほぼ皆無だし

471:デフォルトの名無しさん
07/11/16 13:38:03
はぁ？

472:デフォルトの名無しさん
07/11/16 14:03:31
ム板で騙りとかどんだけ暇なんだよ

473:デフォルトの名無しさん
07/11/16 15:26:33
>>466
>>468
ありがとうございます。
２．のkeepalive socket optionを試してみます

474:デフォルトの名無しさん
07/11/16 15:31:29
keepaliveって検出までに2時間ぐらいかかるんじゃなかったっけ

475:デフォルトの名無しさん
07/11/16 16:17:42
設定できる。
Windowsはタスクごとに設定できる。

476:デフォルトの名無しさん
07/11/16 19:07:36
ほんとだチャンクあったんだ。
でもほとんど使われてないよねこれ。

477:デフォルトの名無しさん
07/11/16 19:20:15
え？apacheなCGIに1.1で喋りかけてみたら、Chunkedな応答を
戻されて焦ってRFC2616読んだ、みたいな経験はないの？
delegateに1.1で中継してもらったら、ChunkedとContent-Lengthが同時に
戻ってきて、MLとかみるとどうみても意図的なRFC違反ですありがとうございました、
みたいな経験はないの？

478:デフォルトの名無しさん
07/11/16 19:22:04
>>476
脳内乙
君はプログラマに向いてません。

479:デフォルトの名無しさん
07/11/16 19:34:56
>>478
あっそwwww
じゃあ実際にコアな部分で使われてるオープンソースのプロジェクトを10個くらい挙げてみてよ。
RFCに準拠させるために実装が必須なサーバは除くよ。

480:デフォルトの名無しさん
07/11/16 20:05:31
Google code searchも知らないし、
Google APIも使ったことないし、
本当にプログラマじゃないんだろ。
荒れるから放置しる

481:デフォルトの名無しさん
07/11/16 20:05:33
例えば2chの.datを全取得する時、大きなものは当然のようにchunkedで返ってくるんだけど

482:デフォルトの名無しさん
07/11/16 20:10:19
もう一つ
HTTP/1.1またはKeep-Aliveで、複数の、
CGIやSSI等のContent-Length不明な物を連続してGETすると
mod_deflateによる圧縮が無ければ、当然chunkedで返ってくるね。
>481のは逆に、圧縮時に圧縮後のサイズが64Kを超えた場合のみだけど。

483:デフォルトの名無しさん
07/11/16 20:17:29
ごめん嘘だ。
HTTP/1.0だったら、Keep-Aliveでも
chunked使われるわけ無いな。強制切断だね。

484:デフォルトの名無しさん
07/11/16 20:18:10
最近のHTTPライブラリでchunkedサポートしてないのは皆無といっていいし、
HTTP系のRPCは全部chunkedサポート前提だろ。>>480にあるGoogle APIとか。

485:デフォルトの名無しさん
07/11/16 21:02:26
chunkedって実装がめんどうなんだよなあ。。。

俺はCGIは全出力結果を取得してからcontent-length付きで投げる派

486:デフォルトの名無しさん
07/11/17 00:19:16
余程レスポンスがでかくなければそれでもいいんじゃね

487:デフォルトの名無しさん
07/11/17 00:48:53
>>485
CGIの場合は特に何も考えずにただ出力すれば
HTTPサーバが勝手にchunkedにしてくれるぞ

488:デフォルトの名無しさん
07/11/17 01:19:32
>>487
受け取る側の実装が、さ＞めんどくさい

ところで一般的なデータの送受信を行う際に、
効率の良いやり方はどんな感じなんだろう？

TAP <--> NIC <------------> NIC <--> TAP
のようなtap間のやりとりをするプログラムを作っているんだが、
max = MAX(NIC,TAP);
while(1){
　FD_ZERO(&read);
　FD_ZERO(&write);
　if ( 出力バッファ > 0 ) FD_SET(NIC, &write);
　if ( 入力バッファ > 0 ) FD_SET(TAP, &write);
　FD_SET(NIC, &read);
　FD_SET(TAP, &read);
　select(max+1, &read, &write);
　if ( FD_ISSET(NIC,&read) ) NICから入力バッファへ
　if ( FD_ISSET(TAP,&read) ) TAPから出力バッファへ
　if ( FD_ISSET(NIC,&write) ) 出力バッファをNICへ
　if ( FD_ISSET(TAP,&write) ) 入力バッファをTAPへ
}
単純に考えたらこれなんだけど、他に何か工夫あるかな？

489:デフォルトの名無しさん
07/11/17 01:35:27
＞＞受け取る側の実装が、さ＞めんどくさい

そのレベルならWinInetでも使ってろ
Winならだが

490:デフォルトの名無しさん
07/11/17 09:13:18
>>488
釣りですかね…

491:デフォルトの名無しさん
07/11/17 09:47:19
無知なだけだろ。放置しる

492:デフォルトの名無しさん
07/11/17 11:27:48
俺には>>488のどこが釣りなのかわからん・・・
誰か解説plz

493:デフォルトの名無しさん
07/11/17 14:28:52
>>492
釣りではないよ

494:デフォルトの名無しさん
07/11/17 14:51:36
selectの引数の数は合ってないし、返値もみてないのに、
律儀にmax取っていたり、釣りか間抜けとしか思えん。
効率とか言っちゃってんのﾜﾛｽ

495:デフォルトの名無しさん
07/11/17 15:40:06
>>494
省略しただけだろ
エッセンスの方を見ろよ

496:デフォルトの名無しさん
07/11/17 16:10:53
おいしい成分は何ひとつありませんでした

ちゃんちゃんw

497:デフォルトの名無しさん
07/11/18 17:55:11
epollを使ってて、切断を検出したいんだけど、
EPOLLOUTが帰ってきたあと、recv(...) == 0だったらclose。
という流れを使ってるんだけど、
EPOLLHUPを使って切断って検出できない？

498:デフォルトの名無しさん
07/11/19 10:16:40
Linuxでプログラム書いてますが、
ソケットの状態を取得する関数はありますか？

getsockoptは状態ではなく設定を取得する関数なので要領を得ません
とりあえず、接続中か接続済みか未接続かを
ソケットディスクリプタから得るだけでもいいです

499:デフォルトの名無しさん
07/11/19 10:44:23
>>498
getpeernameあたり。

500:デフォルトの名無しさん
07/11/19 11:09:21
>>499
なるほどその手があるのか
ありがとう

501:デフォルトの名無しさん
07/11/19 15:44:17
>>497
やりたいのはずばりEPOLLRDHUPでのedge triggerちゃいますの?

502:デフォルトの名無しさん
07/11/19 18:03:29
>>501
エッジトリガっていうのかどうかわ解らないけど、
向こう側でソケットをcloseしても、こっちにHUPが飛んでこないんです
向こう側がcloseしてソケットを閉じたら、HUPが飛んできてほしい。
飛ばない仕様になってるならrecv==0を使うけど。
誰か詳しいひとおせーてください

503:デフォルトの名無しさん
07/11/19 18:13:15
>>502
提供された情報に反応してください。

504:デフォルトの名無しさん
07/11/20 08:52:58
>>503
HUPが来ないんじゃ仕方ない

505:デフォルトの名無しさん
07/11/21 10:20:39
solarisで開発してるんだけど、
ノンブロッキングモード(?)でrecv()の戻り値が
-1なんだけどerrnoが0になるんだが･･･
これってどういう状態なんでしょう？
期待値としてはEAGAIN(?)だと思ってるんですが。

ソケットプログラミング素人にどなたか救いの手をorz。
ちょっと困ってるんでageで。

506:デフォルトの名無しさん
07/11/21 10:32:31
errnoよりperror()が使いやすいよテスト

507:デフォルトの名無しさん
07/11/21 10:35:17
>>506
EAGAINの度にエラー吐かれたらたまらんぞ。

508:デフォルトの名無しさん
07/11/21 10:38:56
そもそもエラってるのにerrnoが0？

差し支えなければ前後のソースを少し晒してくれると

509:506
07/11/21 11:12:59
>>508
ありがとうございます。えっとソースは抜粋＆中略ですが、
大まかな動きはこんな感じです。
現象としては2kbyte程度のデータを流すと一度に取りきれないので、
selectで再ループして残りを取得する動作を期待しているのですが、
２回目以降のrecv()が-1となるのですが、errnoがEAGAINにならないので
エラーになって回線を切ってしまいます。
試しにEAGAINと0を対象として(コメント部)selectするようにしたら、
ちゃんと残りのデータを取る事が出来ました。

while( iLeftOver > 0 )
{
/* 指定バイト数を受信、または通信の遮断まで受信データを取得 */
errno = 0;
if( ( iRcvRet = recv( stSocket, pcBuff, iLeftOver, iFlag ) ) == DCC_SOCKET_ERROR )
{
printf("iRcvRet[%d]／recv()直後errno[%d]\n", iRcvRet, errno);
iErrCode = dwp_getErrNo();

if( EAGAIN == iErrCode )
//if (( EAGAIN == iErrCode ) || ( 0 == iErrCode ))
{
/* 受信準備ができていない場合、selectで受信するまで待つ */
FD_ZERO( &stFdSet );
FD_SET( stSocket, &stFdSet );

dcc_setTimeval( 1000, &stTmVal ); /* 待ち時間は1秒 */

510:506
07/11/21 11:14:48
(一回で送れませんでした。続きです･･･)
iSelectRet = select( FD_SETSIZE, &stFdSet, NULL, NULL, &stTmVal );
if( iSelectRet == DCC_SOCKET_ERROR )
{
/* selectのエラー */
(中略)
return DCC_SOCKET_ERROR;
}
if( iSelectRet == 0 )
{
/* タイムアウト */
　　　　　　　　　　(中略)
return DCC_SOCKET_ERROR;
}
/* 受信を検知 */
continue;
}
/* 受信エラー */
　　　　　　(中略)
return DCC_SOCKET_ERROR;
}
else if( iRcvRet == 0 )
{
/* 通信の終了 */
　　　　　　(中略)
return 0; /* 通信の切断 */
}
/* 一度のrecvで受信し切れなかった場合、受信サイズ、バッファの位置を書き換えて
再度recvを行う*/
iLeftOver = iLeftOver - iRcvRet;
pcBuff += iRcvRet;
}

次ページ