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

主にソケットに関しての質疑応答スレッドです。

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

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port26
http://hibari.2ch.net/test/read.cgi/tech/1269343909/
関連スレ
ネットワークプログラミング雑談
http://hibari.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://hibari.2ch.net/test/read.cgi/tech/1086238859/

過去スレ：
Port27 ttp://toro.2ch.net/test/read.cgi/tech/1293284816/
Port26 ttp://hibari.2ch.net/test/read.cgi/tech/1269343909/
Port25 ttp://pc12.2ch.net/test/read.cgi/tech/1255459388/
Port24 ttp://pc12.2ch.net/test/read.cgi/tech/1246895188/
Port23 ttp://pc12.2ch.net/test/read.cgi/tech/1230466044/
Port22 ttp://pc11.2ch.net/test/read.cgi/tech/1222603744/
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html

図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
　そのソースコード
　http://www.unpbook.com/src.html
詳解TCP/IP〈Vol.1〉プロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
詳解TCP/IP〈Vol.2〉実装
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714957/
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
　http://www.amazon.co.jp/exec/obidos/ASIN/4894716674/
TCP/IPによるネットワーク構築
　〈Vol.1〉原理・プロトコル・アーキテクチャ
　　http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
　〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
　　Linux/POSIXソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/
　　Windowsソケットバージョン
　　http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/

マスタリングTCP/IP RTP編
　http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
　http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
　http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/
Visual Basicではじめるネットワークプログラミング超入門
　http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/

URL抜粋:
★規格
RFC 日本語版リスト
　http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
　http://rfc-jp.nic.ad.jp/link/
RFC Editor
　http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
　http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
　http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
　http://www.iana.org/assignments/port-numbers

★プログラミング
C10K ヘヴィーロードサーバ
　http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
　http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
　http://www.whitefang.com/rin/
Java で packet capture
　http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
　http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
　http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
　http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
　http://X68000.q-e-d.net/~68user/net/

★ツール類
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/

★プロトコル
TTCP
　http://www.sean.de/Solaris/ttcp.html
　http://www.kohala.com/start/ttcp.html
UDP Hole Punching
　http://homepage3.nifty.com/toremoro/p2p/firewall.html

★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm

前スレ修正し忘れた。

ネットワークプログラミング相談室 Port27
http://toro.2ch.net/test/read.cgi/tech/1293284816/

VBでパケットキャプチャをするプログラムを作ったんですが
PCによってキャプチャできたりできなかったりします。
ネットワークカードによってキャプチャできないような
ものがあるのでしょうか？

>>9
ワイヤーシャークとかでキャプチャしてみれば自分のプログラムが
おタコなのかどうかわかるだろう。

>>9
いいえ。

>>9
NICの指定と設定が間違ってる

質問があります。

プライベートアドレスは、ifaddrsなどで取得できるのはわかるのですが、
グローバルアドレスの場合は、プログラムからどのように取得すればよいのでしょうか？
ルータにアクセス？して取得する方法があるのでしょうか。。。

確実な方法としては、外部につないでその結果を返すサーバを作り運用する

授業科目案内トップ ＞ 授業科目案内 教養学部 ＞ 専門科目 産業と技術専攻 ＞ ネットワークとサービス（'12）http://www.ouj.ac.jp/hp/kamoku/H24/kyouyou/A/sangyo/s_1554581.html

>>13
プライベートアドレスもグローバルアドレスも取得方法は同じ。

多段ＮＡＴ

MIT NAT　水戸納豆

>>13です

皆さん、ありがとうございました。
試行錯誤して試してみます！

sendとかwriteとかで、すぐに送信しないでちょっとだけ待つロジック
あれなんて名前だっけか？ どわすれした

思い出しました。 ありがとうございました。

俺は思い出せない、、、なんだっけ

は？
帯域制限のこと？
ロジック？

>>23
アルゴリズムな

NAGELアルゴリズムのことだろ

ナゲル？

なげたらあかん

なんだスタック側の話か
アプリケーションかと思った

そう。パケットを「投げる」からきている。

本人面白いと思ってるんだろうなぁ…

ニコニコ生放送で高速で
アカウント変更とコメントを出来るツールって作れますか？

にしこり

バーレーン

>>30
ﾊﾞｰｶ

BT PANて使ったこと無いんだが、
あれはこのスレの守備範囲なのか？
いちおうソケットだよな？

>>35
プログラミングは関係ないからなぁ・・・

>>34
悔しかったの？ (w

>>37
子ね低脳

>>38
>>37

_ひ

_ふ

ファイル転送するアプリを作っています。

サーバ側に受信ポートを変えて同じEXEを10個立てて、
1000個のクライアントプロセスから10kbのファイルを10個ずつ送信を
行っているのですが、6000ファイルくらい送ると、
クライアント側のconnectがエラーになり始めます。
※connectのerrnoは２（no such file or directory）

これはサーバ側がいけないんでしょうか。
サーバ側のタスクマネージャを見ていても、CPUは張り付いていないし
メモリも食ってないし、帯域もそんなに使用していません。

調査方法でも良いので、どなたかわかりませんでしょうか。

>>42
TIME_WAIT状態のが沢山残っているのでしょう。
netstatで見るとわかると思います。

これを防ぐにはTIME_WAIT時間を短くするか
クライアント側からshutdownさせれば良いはず。

>>42
OS 位書けよ…

まあ、OS 書かない奴の大半は Windows だろうからそれを仮定するけど、
connect( ) 失敗時に見るのは、errno じゃなくて、 WSAGetLastError( )
じゃないのか？

>>44
OSはz/OSです

>>43 たしかに　TIME_WAIT　と　CLOSE_WAIT が沢山ありました。。。

>>44 すみません、Windows2008ServerR2　同士　です

クライアント側の問題だと思うよ（TIME_WAIT累積によるローカルポート枯渇）。
クライアント側もz/OS？何台のマシンでやってるの？

>>46
そんなＯＳないしw

TIME_WAIT周りに不具合があるみたいだな。
http://salaryman-life.blogspot.jp/2012/04/windows-server-2008-timewait.html

CLOSE_WAIT が残っているのはロジック見直した方がよいと思う。
切断手順がおかしいか

>>47　クライアント側もWindows2008serverです。
　　　（z/OSではないです）

TIME_WAIT　と　CLOSE_WAIT が両方あるってどんな繋ぎ方してるのよ？

なんだよWindowsかよ（このやろ!!>>45）。
レジストリで
・使えるローカルポート数を増やす（デフォルト5000個のはず）
・TIME_WAIT時間を短くする（Windowsのデフォルトは凄く長かったと思う）
くらいしかないだろうなあ

>>51
OS/360にしとけば良かったw
ｺﾞﾒﾘﾝｺ

>>46
だから、Windows 系なら errno じゃなくて、WSAGetLastError( ) 見なよって
書いてあるんだが…

話は、それからだと思う。

>>53 すみません、遅くなりました。
　　　WSAGetLastErrorだと、　10061 　が返ってきています。

>>54
10061　WSAECONNREFUSED　Connection refused.
まんまですな。

で、Shutdown() しているのはどちらから？

>>54
接続切断回数を減らすか
>>51 の言っているようにレジストリをつつくかだな
TcpTimedWaitDelay　MaxUsePorts ぐぐれ粕

>>54
WSAECONNREFUSED だから、サーバー側で Listen しきれてないんだろうな。

他の人も言ってる様に CLOSE_WAIT 状態が続いてるのは普通はないから、
クローズ処理を見直したほうがいいと思う。

自分で良くわからないなら、まずはサーバー側とクライアント側の netstat の
概要と、サーバー/クライアントの切断処理を晒せばここの人が何とかしてく
れるかも。

そもそも切断処理をしていないとか。

すみません、諸事情でマシンをさわれませんでした。

ソースコードを見直したところ、connectリトライや切断の際に
処理がおかしい箇所があったため、見直して修正しました。

そしたら、CLOSE_WAITはなくなりましたが、TIME_WAITは
かなり発生しています。
また、connectエラー（10061）は相変わらず出ます。
レジストリをいじって、TcpTimedWaitDelay　を30にしたところ
だいぶ減ったのですが、10061エラーはあまり改善していません。

調べてみたところ、TIME_WAITは出ても問題ない、どうやっても
出てしまうもの。という記述を多くみました。
とすると、やはりTCPの仕組み上の限界なのでしょうか。

>>59
CLOSE_WAITとTIME_WAITが同時にあるのはおかしい常態だけど
どんな接続や切断の仕方している？
接続はクライアントから? サーバから? 切断は?
どの位の時間間隔で接続数は?

それからTIME_WAITは先に切断要求を出した方に残るのは正常な状態。

ん？ connectリトライって何やってんの？
tcpはリトライなんかしちゃいかんよ。

ネットワークのトラブルとかで、connect( ) が一時的にエラーになることもあるから、
常にリトライしないとか言うアホは放置で。

>>59
TcpTimedWaitDelayが30秒だと30秒以内の間隔で連続して
接続・切断を繰り返すとソケットが破綻するのはわかるかな？

>>62
ごめん、言葉足らずだった。
connectから応答がないときのリトライ。
接続できないからと数秒間隔でリトライとか。

Windowsの場合、connectは20秒なんで20秒で繋がらない
状態の場合は直ぐにリトライしても繋がることはほとんどないが。

>>60
CLOSE_WAITはなくなって、TIME_WAITだけある状態です。
・接続は、クライアントからconnectしています。(bind無し)
・切断は、クライアント
　　　　　　→セッション終了を示すコードをsendで送ったあとは
　　　　　　　自らshutdown(cs,2); closesocket(cs);　で閉じてます。
　　　　　サーバ
　　　　　　→セッション終了を示すコードがrecvで届いたら、
　　　　　　　こちらも自らshutdown(cs,2); closesocket(cs);　で閉じているので
　
なので、切断は同期があまり取れていないのですが、まずいでしょうか。


>>61
connectでエラーが帰ってきたら、5秒待って再度connectしています。
これはまずいでしょうか。。。

>>63
確かに。。。明らかに30秒以内で接続・切断を繰り返しています。
10KB＊10ファイルを1セッションで送るプロセス＊１０００個を同時起動
なので、やはり多すぎでしょうか。。。

>>65
shutdown は SD_SEND　でやるのがお行儀の良いやり方だけど
SD_BOTH でも問題は発生することはないんじゃないかな。

>セッション終了を示すコードをsendで送ったあとは
これは何?

connect()は問題なし。

>なので、やはり多すぎでしょうか。。。
切れ目無く連続でやると破綻するでしょうな。

例えば、だけど
0xFFを「終了の合図」と決めておいて

クライアント側は
　0xFFを送る　→　shutdown
サーバー側は
　0xFFを受け取る　→　close
ということだろう。

普通に作るならば、クライアント側から切断するのであれば
サーバー側はCLOSEのサイン(recvが0)を待てば良いだけな気がするし
そもそもSENDをshotdownするなら、終了の合図なんて要らないんだけどね。
まあ、将来の可能性も含め、切断せずに繰り返し送受信することを考慮するなら、
そういうやりかたもあるかとも思うけど、
切断時に、両方ともCLOSE前に自分で切ってるのはどうなんだろうね。

C#なんですが
データグラム ソケットで送信されたメッセージが、内部のメッセージのバッファーまたはほかのネットワークの制限を超えています。または、データグラムの受信に使われるバッファーがデータグラムより小さく設定されています。
というエラーが出ることがあるんですがこれはどうすればいいでしょうか？

分割するとか
C#に限らないんじゃ？

Socket.Receiveするときにバイト数を指定すればいいですかね
指定した SocketFlags を使用し、バインドされた Socket から指定したバイト数のデータを受信して、受信バッファ内の指定したオフセット位置に格納します。

>>67
仰るとおりの終了の合図をやっています。

切断時に両方からshutdown , closesocket　はまずいのでしょうか。
あまりそのあたりに触れているサイトが無くて困っております。

また、今再度確認していて気づいた点があります。
1000プロセスの終盤（残り10プロセスあたり）になると、
connectエラーは起こらないのですが、recv（の前のselect）が
5秒待っても届かずタイムアウトが猛烈に発生します。

この場合、TIME_WAITは30秒経過したからか、殆どなくなって
ESTABLISHEDばかりですが、なぜか非常にrecv,sendが遅く
なっておりました。

NICやHUBが限界なのかなと思えてきました。。。

その切断の仕方だとサーバ側も（タイミングにより）TIME_WAITになるよね？
>>67が言ってるように、サーバー側の切断は「終了の合図」でやるのではなく、
recvで0が返ってきた時にやるようにすれば問題ないと思うけど。

>>70
普通にsend側で分割する。receive側でサイズ指定してもダメ。

>>71
>切断時に両方からshutdown , closesocket　はまずいのでしょうか。

問題ないです。

>あまりそのあたりに触れているサイトが無くて困っております。

Winsockと言えばここでしょう。サンプル見れば切断手順がわかると思います。
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

>1000プロセスの終盤（残り10プロセスあたり）になると、

1台のＰＣで1000プロセスだとそもそも無理があると思いますが。

>connectエラーは起こらないのですが、recv（の前のselect）が
>5秒待っても届かずタイムアウトが猛烈に発生します。

select()のタイムアウトとは?

>NICやHUBが限界なのかなと思えてきました。。。

そりゃ無いです。ファイルコピーなんか何百ギガも転送したりしますんで。

DoS攻撃認定されてブロックされてる、とか言うオチはやめてくれよ。

>>75
昔、俺もやらかしたな
ネットワーク構成図に載ってないFWが間にあって、通信を殺されてたｗｗ

そんなんだと割りと簡単にわかるだろう

>>71
クライアント側は１台で１０００コネクションなんてことは無いでしょうから
TIME_WAITで破綻なんかしないのでは？
テストのやりかたが悪いと思う。

すごく初歩的な質問で申し訳ないのですが、現在コンピュータが行っている接続を
すべて取得する手段はどのようなものが考えられるのでしょうか。

>>79
netstat -a

そーだね

WiFiでPCからAndroidに作業をさせるようなアプリを作っています。

サーバ側をAndroid、クライアント側をWindowsXP、IPとPort固定で接続しています。
クライアントからサーバに接続しようとすると、初回はだいたいうまくいくのですが
BindException: address already in useが出て接続できない時があります。
ServerSocketクラスのsetReuseAddressやsetSoLingerなどのメソッドを試してみましたが
それでも接続できないことがあります。
Java（というかTCP）の仕様なのでしょうか？
希望としては接続・切断を繰り返しても問題なく接続できるようにしたいのですが、、
いい方法があれば教えてください。

>>82
少し前にもあったけど、どの程度の頻度で接続を繰り返しているのか？
切断手順に誤りはないか？をまずは確認してください。

頻繁に接続切断を繰り返したり、数分間切断された状態が続くとやばい
とかなら、素直にUDP使っとけやと思います。

>>82
＞IPとPort固定で接続しています。
もしかしてクライアント側も特定ポートにバインドしてるとか？
＞BindException: address already in use
はまさにそれっぽいんだが

>>84
次はサーバ側が多重化されていないので問題が発生する
とエスパーしてみる。

ありがとうございます。

>>83
30秒〜1分くらいです。
切断手順は、shutdown→closeみたいな感じでしょうか。
今はcloseだけ行っています。

>>84
クライアント側もサーバのポートを指定して、サーバに接続しています。
サーバ側でBindは呼んでいますが、クライアント側では意識してBind呼んだりは
していません。

>>86
>今はcloseだけ行っています。
お行儀わるいぞ。こうだろ。

shutdown(send) → recv(0) → shutdown(recv) → close

>>87
そんなことやんねーよバーカ
何年前の世界に生きてんだ

>>88
そ、そうなのか・・・w

>>89
相手が切断したことを確認する必要があるかどうか
無いならいきなりcloseでいい

>>85
俺の過去が見えるのか！

久々に来たけど、ここ相変わらず面白いね。
無知とは言え無茶しすぎだろう。

自分の管理下のpcや鯖相手に好き勝手試すのはどうぞ存分に遣ってくれと思うけど、ネット上の鯖とかには控えめにな。サーバ攻撃受けたと判断されて通報されそうだわw

『朝鮮総連』は色々な企業のホームページからホストコンピューターに進入し、自分達が隠したプログラミングを引き出す…他人の会社のサーバーに『挺陝馗操作』や『改竄red-hat』のクラッカープログラム保管場所にしている。
札幌市立啓北商業高校の野島(横濱)えり Microsoft USA co.tp.
弖十＝TEN10(teto)＝優多野手頭＝野慈蚕＝帝跿(徒)＝衛鴉朧 笑狸乃雉匯

>>90
shutdown(both)も要らないのか?

>>90
大した手間じゃないんだから定石通りの
切断手順を踏んだ方が良いと思うけどね。

>>94
close内で勝手に呼び出す

>>95
カーネル内部で定石通りに勝手にやる

>>96
カーネル側でちゃんと処理してくれないＯＳもあるのか?
でなきゃTIME_WAITもあるし常にclose()のブチ切りで良くなる。

>>86
＞30秒〜1分くらいです。

＞サーバ側でBindは呼んでいますが、クライアント側では意識してBind呼んだりは
＞していません。

だとすると、それにも関わらずBindException: address already in use
になるのは変だね。実は切断がちゃんと出来てないとか、クライアントの
マシンで別のアプリが大量にポート消費してるとか？netstatは見てみた？

>>98
Bind()しているのはサーバ側のリスナーのポートだけじゃない気がするw

>>97
だから基本的にはclose()ブチ切りで問題ない

shutdown()を使うべきなのは、データ送信後に相手が
受け取れたかどうかを見届けたいときくらいなものだ

>>100
shutdown(SD_BOTH)の存在価値は全くないと・・・

そもそも shutdown( ) [通信の停止] と close( ) [資源の解放] は、用途が違うんだから、
ぶち切りなら shutdown( ) は不要とか言ってるアホはスルーでいい。

プログラムの作りによって、通信はやめたいけど、資源の解放はあとの方でまとめてや
るなんてことはいくらでもありうる。

※ しかし、なんで shutdown( ) なんて名前なんだろう？
※ 素直に disconnect( ) とかでいいように思うが、8文字制限か？

serverとclientを区別するためジャマイカ

>>102
そういうときだけshutdown使えばいいじゃん
適材適所って言葉知ってる？

unixの実装だとまずい事が起きる場合があるそうですな。

2.6 shutdown() はどういうときに使うべきなのですか?
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-2.html

winsockだと大丈夫かな。

ソケット周りはBSDの実装をずーっと引きずっているし
高速回線にはそぐわないパラメータ値も多いし。

>>104
>適材適所って言葉知ってる？

だから、単純に

shutdown()を使うべきなのは、データ送信後に相手が
受け取れたかどうかを見届けたいときくらいなものだ

>>107
途中で送信しちゃった。

>適材適所って言葉知ってる？

だから、

> shutdown()を使うべきなのは、データ送信後に相手が
> 受け取れたかどうかを見届けたいときくらいなものだ

以外のケースもあると書いてあるんだが、日本語理解できない？

それとも、なんか悔しかったのか？(w

あとでまとめて資源解放って、作りの良さ的にはどうなんだろうか

>>109
あとでまとめて解放なら放置プレイしてＯＳに解放させれば良いのでは？

それならさっさとクローズした方がいいな。

お気軽に都度プロセス起したり頃したりする組み方のサーバーやクライアントの通信モジュールなら有だと思う。

fdをそのソケットにかかわる他のプログラム内部資源の識別にも使っている作りだと、
通信の停止とclose()を別々に行うことはあるね。
あまりいい作りとは思えないけど、手軽なんで周りでも時々見かける。

>>113
なんにせよshutdownしてcloseせず長々と持ってるつくりは
感心できるものじゃないなぁ

>>102
> プログラムの作りによって、通信はやめたいけど、資源の解放はあとの方でまとめてや
> るなんてことはいくらでもありうる。

こんな作りにしたこともしたくなったことも、いまだかつて無い。

論破したくて無理やり思いつきました

ぶち切りって、あんまりファイヤウォールでは想定されてなくて、暫く続きのパケット来るか待ち続けちゃってそうw
一万セッションぐらい通してみて誰か耐久試験でもやってくれw

ftpなんかも制御持ち切りでデータのほうばっかで流してるうちに、切られてたりはするな。
ゲームとかでも描くパーツの制御にそれぞれ制御セッション貼って、データだけいろいろ送って、状態推移に使ってたりして。

>>112
tftpなんて毎回貼り直しでもいいくらいヌルいね。
httpなんかでも地図データ拾うのに使い捨ての様にセッション貼ってるけど。

>>117
その耐久試験ならすでに何億回とやってる。

どちら側も同じポート番号で複数の接続を処理する場合、
shutdownだけしてcloseする処理はありうる。
ずっと待ち受け続けられるから。

ただクライアントサーバ方式全盛だから、
こういうランデブー型の双方からconnectする通信方式は少ないな。
ちなみにTCPのRFCにはランデブー型APIについて書いてあった。
BSDソケットはこの辺を生真面目に設計、実装していると思われる。

>>119
> shutdownだけしてcloseする処理はありうる。
< shutdownだけして、closeせずにsocketを維持し続ける処理はありうる。

>>120
いや、そんな行儀の悪い対向はそうそういないだろうよ・・・
shutdown送ってんのにペラペラ喋り続けるやつは
問答無用でぶっ殺すわ・・・

shutdownしたら、connectしなおすんですよ。

You're correct.

>>117
close()でぶち切りしてもプロセスをKillしてもOS側で必要な切断手順は
やってくれるのでプロトコルの途中でのぶち切りにはならない。

closeというかCloseHandleを無視するとかいうイカレポンチな代物がWindowsにはあったりするからなー(棒
ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms724935%28v=vs.85%29.aspx

WinsockはclosesocketとshutdownのMSDNドキュメントは必ず読まないとヤバイ。
Graceful Shutdown, Linger Options, and Socket Closure.も読んどけ。

>>116
そんなに悔しかったのか？ (w

>>124
いったいどこのプロトコルの話をしてるんだ？

>>124
安いプロトコルスタック買っちゃったら
このあたりの尻拭いしてくれないよね

SSL Proxyの簡単なやつを作ってみたいのですが
何か参考書知りませんか？
LinuxかAIXでプログラム作れたら嬉しいです

winsockとかなんちゃってipスタックだとその辺適当で、上手く動かない罠に嵌るだろうな。
枯れてるipスタックって結構大事。

aixならibmの営業捕まえて研修受けてこい。もちろんお金は掛かるけど。
簡単にsslでproxyできたらsslの意味無くなると思うけどね。
あんたが銀行サイトにsslで繋げて安全と思ってるのに、途中でproxy挟まれて中身見れてたら意味無いでしょ。

趣味でやってる程度なので初歩的な質問ですいません。
以前TCPを利用した対戦ゲームを作って友人と遊んでいたのですが、
引越しで環境の変化により接続できなくなりました。

原因はマンションの回線を使っているためだと思われます（そもそもポート開放できない
が、プログラムの組み方でその辺の問題を回避できたりしますか？
ネットゲームや、DS・PS3等のネット通信はできるので、接続は絶望的ではないのかなと思い質問しました。
TCPでの接続ができないとしたら、他の通信方法などがあれば教えてもらえると嬉しいです。

可能です
では次の方どうぞ

>>131
VPNでつないどけ

セルンか

両端ともCATVみたいにNATの内側だとつらくね？

メールベースで互いの行動をやりとりする

>>135
SoftEtherでも使っとけ

>>137
誰でも使えるpublicなサーバーとかあるんだっけ？

>>135
物理層を伝書鳩にすればいいと思うよ。

>>139
それでもダメだろ。面白いこと言ったつもりだろうけど、よく考えろ。

やっぱ物理層はスマホだよな

ネットワークプログラミングって固定長が基本なのですか？
送られてきたデータをパースするときは、どんな感じでパースしてますか
普通に固定長ファイルを扱う感じでやろうかと思うのですが

いえ、(可変長な)テキストが基本です。HTTPもFTPもSMTPもPOP3もみんなテキストです。
DNSはバイナリですがやっぱり可変長です。

>>143
回答ありがとうございます。
ネットワークプログラミングってパフォーマンスを考えなければ簡単そうですね
ちょっと面倒なファイルの操作ってイメージ

レイヤによる

分散コンピューティングになるので、
ローカルファイル扱いとは
本質的に違うところが随分あります。

ネットワークカメラからデータ受けたり、ネットワークプリンタにデータ吐いたりするのも
ネットワークプログラミングなので、一律に「分散コンピューティング」とか言うのは、
すごく違和感がある。

HTTPで302が来た場合一旦socketをcloseして繋ぎなおしたほうがいいですか？
それともリクエストをやり直すだけでOKですか？
また、こういう情報はどこに記載されています？

RFC

>>149
RFCの何番かくらい教えてやれよ・・・

簡単なチャットプログラムのようなものを作りたいんだけど
UDPでブロードキャストしまくるのって下品？

簡単なチャットプログラムのようなものならいいんじゃない？

ブロードキャストで届く範囲ならいいんじゃないの？
所詮チャットて程度の帯域利用なんだから。

それで自分だけは他人宛のメッセージを読めるようにすると

DNSに関したプログラム作りたいんだけどまずUDPしっかりやってからですかね？

UDP自体にしっかりやるほど難しいことはありません
それより関連RFCをよく読んで仕様を頭に叩き込んでください

aとかaaaaとかptrとか引いて喜んじゃう程度なら
頭を叩いてまで詰め込むようなことはないような。

ネットワークプログラミングやってみたいんだけど、何か面白そうなお題ない？

p2p

最初はチャットからだろうな

ゲーム

winsock2を使用してUDPのデータ送信プログラムを作成しています。

sendto()に10000バイトを指定して実行し、戻り値が10000である事を確認しました。
この状態で送信先のPCにアナライザソフト(PacMon最新版)を入れてデータを確認しましたが、
1パケット分(パケット長1514バイト、データ長1472バイト)しか届いていません。

残りのデータは何処に行ってしまったのでしょうか?
2台のPC共にネットワークカードのジャンボフレームは無効にしてあります。

気にするな

Wiresharkでキャプチャしてみるとどうなるかな？

>>162
おれが食っちまった

>>125
最近はＭＳＤＮもメトロデザインなのね。
なんか殺風景なのね。

>>162
天使の取り分

分け前じゃなかったっけ？

て言うか、8割以上ぶんどる天使って、悪魔じゃねーのか？(w

100送って1しか届かなくても、残り99が後から届かないとはかぎらない

Wiresharkを使って見ましたが1パケットも届かなくなりました。
送信バイト数を10Kではなく1KにするとWiresharkでも届いてる事を確認できます。

普通は複数パケットに分割されて届くのでしょうか?
それともsedto()の戻り値が10Kなのが変なのでしょうか?

UDPなら魔空空間に呑まれて終わりだろ

Wiresharkを使って見ましたが1パケットも届かなくなりました。
送信バイト数を10Kではなく1KにするとWiresharkでも届いてる事を確認できます。

普通は複数パケットに分割されて届くのでしょうか?
それともsedto()の戻り値が10Kなのが変なのでしょうか?

UDPならどこで蒸発しても文句は言ってはならない…
…たとえそれがNIC(って最近オンボードの方が多いけど)に渡る前であっても、
send(to)に渡した直後であってさえも、だ…

>>1
Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
以下略

こまけえことはきにするな

>>172
環境依存です。
今なら複数パケットに分割して配信する環境の方が多いでしょう。
実際にどうなるかは、経路上のネットワーク機器次第なので、
インターネットでどうなるかは運次第ですね。

>>176
＞今なら複数パケットに分割して配信する環境の方が多いでしょう。
UDPを分割配信する処理系があるならぜひ教えてもらいたいものです

え？

>>177
WindowsとかLinuxとか

>>172
IPフラグメンテーションという仕組みがあり、UDPパケットのサイズが大きく
MTUのサイズを超えてしまう場合には、複数のIPパケットに分割して格納される。
ただしルーター側で無効にしている場合もあります。

PacMonやWiresharkでUDPパケットをキャプチャー出来ないのは、
おそらくIPフラグメンテーションで分割されたUDPパケットを解析する
機能が無いからです。

IPパケットを自力で解析すれば、そこには分割されたUDPパケットが
格納されてると思います。

>>180
>IPフラグメンテーションという仕組みがあり、UDPパケットのサイズが大きく
>MTUのサイズを超えてしまう場合には、複数のIPパケットに分割して格納される。
>ただしルーター側で無効にしている場合もあります。

・その分割されたパケットはどこで(ex: 受信側のUDPスタック)組み立てるの？
・分割された複数パケットの到着順序が崩れたり(or 反転したり)、ロストした場合はどう振る舞うの？
・これらはプロトコル仕様書(RFC)のどこに記述されているの？

IPフラグメンテーション機能が活躍するのはTCPの場合だけだよ
UDPやICMPといったプロトコルの場合、
・送信側UDPスタックでは、IPヘッダ内にあるフラグメント禁止ビットをオンにしてパケットを送信
・途中のルータはフラグメントが必要になった場合、(フラグメント禁止だから)パケットを破棄し、
　送信元へはICMPの未到達(unreachable)メッセージを返す
というのが一般的な実装だと記憶していたのだけどなあ....

>>181
>・その分割されたパケットはどこで(ex: 受信側のUDPスタック)組み立てるの？
受信側のIPスタックが組み立てるにきまってるだろ。

>・分割された複数パケットの到着順序が崩れたり(or 反転したり)、ロストした場合はどう振る舞うの？
複数パケットの到着順序が崩れたら、正しい順番に並びかえる。
ロストしたら破棄される。

>・これらはプロトコル仕様書(RFC)のどこに記述されているの？
STD-5だよ。

>・送信側UDPスタックでは、IPヘッダ内にあるフラグメント禁止ビットをオンにしてパケットを送信
>・途中のルータはフラグメントが必要になった場合、(フラグメント禁止だから)パケットを破棄し、
>　送信元へはICMPの未到達(unreachable)メッセージを返す

それこそRFCの何処に書いてあるんだよ？

また馬鹿がわいてるな
APでやれよ162

UDPでIPフラグメンテーションなんて使うな。仕事だったら地獄を見るぞ。
暇つぶしならどうでも良いけど。

TCP/IP
UDP/IP

>>182
>受信側のIPスタックが組み立てるにきまってるだろ。

ほう、IPスタックに分割されたパケットを組立てる機能があるとは初耳だ
自分の知識ではIPパケットの組み立ては(受信側の)TCPスタックの機能なんだけどね....
それはどこに書いてあるの？(RFCならbestだけど、解説文書へのリンクでもokだよん)

>複数パケットの到着順序が崩れたら、正しい順番に並びかえる。

これも「どこ」で処理されるの？UDPスタック？ それとも アプリケーション？
自分の知識ではパケット順序性の保証はTCPスタックの機能(責任)なんだけど、
今の議論の文脈だと「TCPは無関係」だよね？

>STD-5だよ。
RFC番号をヨロシク

>それこそRFCの何処に書いてあるんだよ？

まず自分のカキコに誤りがあったので訂正する
送信元へ返されるICMPメッセージについて、>>181では「未到達(unreachable)」と書いたけど、
これは "fragmentation needed and DF set" に訂正する

次に、この自分は知らないよ
少なくとも RFC 768 - User Datagram Protocol に、IPフラグメントに関する記述は無い
というか、そもそもUDPではパケットが分割されることを想定して設計されていない
送信元が分割(フラグメンテーション)が起きない長さで送出することを期待している
これを実現するのが RFC1191 - Path MTU Discovery だ
日本語で書かれた解説へのリンクを紹介しておく

＠network Cisco・アライド実機で学ぶ　＞　TCP/IP入門　＞　Path MTU Discovery
　http://atnetwork.info/tcpip/tcpip91.html

無知すぎて話にならない

細かい点でタイポがあったので>>186を訂正
X: 次に、この自分は知らないよ
O: 次に、これが何処に書いてあるのか自分は知らないよ

あと、"fragmentation needed and DF set" の DF は don't fragment の略語

色々アドバイス有り難うございます。

難しくて理解できていませんが・・・

1,環境依存である。
2,送信側から10Kを送信しても途中の機器が10KバイトのMTUに対応していない場合には、
　分割される。(UDPも分割される???)
3,分割されない場合には破棄されて、ICMPエラー通知が届く。


1と3の状況なのかなぁと思っています。
対応しているMTUを越えた場合に全部が破棄されずに先頭1514バイトだけが届くなんて事はありえますか?

パケット監視じゃなくて受信してみろよ

>>186
>ほう、IPスタックに分割されたパケットを組立てる機能があるとは初耳だ

そうか。勉強になってよかったな。
その事もSTD-5に書かれてるから読んだ方がいいよ。

>>複数パケットの到着順序が崩れたら、正しい順番に並びかえる。
>これも「どこ」で処理されるの？UDPスタック？ それとも アプリケーション？

IPスタックが処理するんだよ。

>RFC番号をヨロシク
（´・ω・`）

>まず自分のカキコに誤りがあったので訂正する

細かい間違いを論ったりするほど狭量じゃないから安心していいよ。

UDPを再結合なんて聞いたこと無いんだが
どこの惑星の話？

ああ、IPの分割とごっちゃになっちゃってるのか

銀河帝国だろうjk

>>187
残念ながらわが国にはそういう輩がＳＥやプログラマーと名乗っているのだよ。
他の技術系の職種では信じられない事であるがな。

昔は元コンビニ店員がいたなー、もちろん経験０

>>189
>先頭1514バイトだけが届くなんて事はありえますか?
180にも書いたが、恐らくはちゃんと10KB全部ちゃんとネットワーク上を流れている。
ただ189の知識不足できちんと解析できていないだけ。

184や186の言うとおり、UDPはMTUサイズを超えないように使うのが一般的だし、
MTUサイズを超えた場合は通信障害が起きやすくなる。

素直にUDPパケットが1KB程度になるようにプロトコルを設計しなおした方がいい。

そういうのってユーザプログラム側が意識しなくてもいいようになってるんじゃないの？
ドライバ作ってるとかならそうなんだろうけど

>>198
UDPはデータは消えてなくなっても文句を言えない仕様だから
結構意識する必要がある
でかいパケットはまず間違いなく後ろカットされるし

仕様に定められているものを仕様通りに使って問題あるかもしれないってのは
また別の話だと思うがな。

でかいパケットはドライバ側がやる仕事だろう
プログラム側は一度に送ろうが小出しにしようが関係が無い

本スレ>>1の「Programming UNIX Socket FAQ (日本語訳)」には、
まさに今回の現象(>>162)が解説されている

Q: 5.8 データグラムの最初の部分しか届かないんですが、どうしてなんでしょうか?
A: プラットフォームによっては(MTU値のため)データグラムを分解し、
　そして相手側で再構成させるIP断片化をサポートしているものもありますが、
　しかし全ての実装がこれをサポートしているわけではありません。

で、Windows実装はというと、同じ>>1の「Winsock Programmer's FAQ (日本語訳)」によれば、

Q: 3.6 - UDP って何? どんな制限があるの?
A: プロトコルスタックは、UDPデータグラムの大きさがネットワークのMTUより大きいときは、
　データグラムを分割します。通信相手側のスタックはその分割片から完全なデータ グラムを
　再び組み立ててから受信側のプログラムに渡します。もし分割片の一部が失われたり
　壊れていたりしたときは、そのデータグラム全体が捨て去られます。このため、
　巨大なデータグラムを送るのはあまり実用的ではありません。例えば、8KのUDP データグラムは、
　Ethernet 上に送信されると、6つの塊に分割されます。もしこの6個の分割片のう ち一つでも
　喪失したり壊れたりすると、8Kのデータグラム全体が捨てられてしまうのです。

とあり、Windows実装では(効率性を無視すれば)分割/再構成ともサポートされていると解釈できる
でも、これでは今回の現象(>>162)を説明できない
正しく実装されているなら、全データ(10KB)が到着するか全て破棄されるかのどちらかになるはず
>>162の現象把握のどこかに見落としがあるのか、それともこれらFAQ集に誤りがあるのか....？？？

おつむがなければMSにお布施を払って聞けよ

>>202
再構築はOS側のスタックで行われるが、
>>162はアナライザで見てるから。

久々に伸びてると思ったら
何年も前の話がループしてるのか

誰もが通る道だからかと

とおんねーよ

誰かが通る道だからかと

なんのために過去スレがあるんだ

あなたは幾多ある過去スレすべて目を通しましたか？

>sendto()に10000バイトを指定して実行し、戻り値が10000である事を確認しました。
10000バイトの中身を比較したとは書いてないところが...

>>211
落ち着いて>162を読み返すんだ

送れた事実が書いてあるだけで
受け取ったとは書いてないような？

>>212
落ち着け
比較した結果もそこに書いてある

おk
深呼吸した

全部受け取ったとは書いてないような？

受信できるか保証されてないのに、分割送信しようとするのはおかしくねえか？

受け取れませんと質問してるのに、比較しろというのはおかしくねえか？

自分で答え書いて、それ以上のことができるとでも言ってるのかな？
できないなら、それ踏まえて、別な方法考えないと

>>217
分割しようがしまいが受信できる保証はないが？

深呼吸しようぜ
・10000バイト、Winsockにデータを与えた(この時点で送信などしていない)
・データを受け取りましたと返した(同上)
・相手の状態見たらさきっぽだけ出てきた(少なくとも、さきっぽだけ送信側が送信した)
なにもおかしくないよね

ip fragment(rfc791)
やりますとは書いてあるけど、実際やってどうなるかの保証はないでしょ、UDPだから

MTUが512を想定して、考えたな、昔

データ受け取ってないから問題なんだよ。
アナライザで見ただけ。
最初に受け取るコードかいてりゃこんなとこ来てないｗ

同じ轍を通ってることを嘲笑うだけで誰一人解決策を出せないｗ

まわりくどい言い回し、ほのめかし、あざけり
このスレの住人の得意技だね

解決策ってなに？
アナライザに10000バイト表示されればいいの？

>>226
すでに何人からか指摘があるけど、断片化が発生しないよう十分に小さなサイズでsendtoすること
もし大きなデータを送信したいのならアプリ側で分割/組み立て機能を実装する(TFTPのように)
IP層での断片化はRFCで仕様としては定義されているけど、その実装は必須ではないから環境依存

PacMonだと最初の１パケットだけ見えて、Wiresharkだと何も見えないって
アナライザの使い方間違っているとしか思えないんだが

UDP軽いらしい
・本読まない
・仕様はいわずもがな
・実装もしらない
・調べる気もない
・金を払うきもない

>>223
10000バイト受け取った　か　何も受け取らなかった　の 2択ですしー

IPフラグメンテーションを見たいなら、UDPじゃなくて
ICMP Echo（ping）で試してみれば良いのに。
WindowsでもLinuxでも10kバイトくらいなら何の問題もないが。

>>231
いや、IPパケットの分割そのものはTCPで必須だから、どのアナライザでも見えるはずなんだよ
でも、「UDPデータグラムの分割(=断片化)」というのは常識的には想定されていないグレーゾーンだから、
アナライザ側での対応も解析可否を即答できる人はかなり限定されるんじゃまいかと
どうしても知りたいのならフリーならフォーラムへ有償ならベンダーへ問い合わせしたほうがいいと思う

自分なら最も素朴で実績のあるアナライザである、UNIX(Linux or Mac)のtcpdumpを使うけどね
最悪、-xオプションで全フレームを16進ダンプして自力で解析プログラムを組むことも考える

追加
・パケットアナライザーも使えません

いうことありません

>>210
昔、TCPサーバアプリを作る時に過去スレ全部見たな〜
おかげで初めて作ったTCPアプリだったが何年も何の問題もなく動いている。

過去スレより、他の解説サイトやソース読めと思うのはオレだけだろうか

>>232
IPフラグメントの話で、なんで上位層のTCPとかUDPとかが出てくるんだろう？

>>236
何、言ってんのか、わからんのだけど

>IPパケットの分割そのものはTCPで必須

この意味がわからん。

>>235
このスレで紹介されているサイトや スティーヴンスの本も読んだよ。
ここは９０％以上ゴミレスだけど時々神が降臨されるのさ。

>>239
ソースは？

>>180で答え出てるのに、何処まで混ぜっ返すんだよ。
>>181が馬鹿な回答するから、質問者を混乱させてるんじゃないか。

それっぽいオプションがあるみたいだね
http://wiki.wireshark.org/IP_Reassembly

TCPの送信段階で分割したような動作になってるだけでしょ
データを保証しないといけないからね
IPとして処理される段階ではMTUとかに合わせたサイズになっとる

久々に伸びてると思ったら
何年も前の話がループしてるのか

>>244
>>205
何年も前どころか二日前の話がループしている。

>>243
> TCPの送信段階で分割したような動作になってるだけでしょ
> データを保証しないといけないからね

あのね、UDPの話で始まってるのよ。
状況とTCP/IPの仕様をちゃんと把握してないのに適当にレスする奴多すぎw
>>232とか斜めすぎて意味がわからん。

tcp/ipスタック実装したことない人には何言ってもわからんかもね

>>232はジョークだろ

>>232は
・IP層の断片化 (途中経路でも起きる。only IPv4)
・TCP層のセグメント分割 (peerのみで行われる)
を区別できてないだけ。
どちらもMTUが絡むから、初級者によくある混同で、それほど意味不明でもない。
ただしUDPについて推測で発言しているから、相当おかしい内容になってるけれども。

実装依存な話でお互いが正義と主張してるだけに見えるな。

インターネットに流すならルータがめんどくさいなって思ったら容赦なく捨ててるから届かないって感じだ。
今はicmpで通知しても安物ブロードバンドルータが捨ててしまうからねえ。

送る側で小さくしてみてどのくらいなら通るって試行錯誤しながら送るしかない。ファイルベースなら512バイトずつ読んでるはずだから、512バイト読んでそのまま送ればいいんじゃ無い。
２セクタ読んで1024バイト送ってみてどのくらいパフォーマンス上がるかも環境次第だしねえ。

lteとかwimaxとかで帯域制限された／混雑時の送信ノウハウなんてのも必要なのかもしれない。128kbps制限とかされたらまず送ってもエラーだしね。

アプリ層で小さくだの大きくだのして意味あんの？

UDP使うんだと意味あるだろ

>>250
そういう話じゃねーよ。>>181>>232は明らかに仕様を理解してない。

>>250
バカの長文乙

250は間違ってことは書いてないような

お前も同類か

UDPで落ちないようにがんばるくらいならTCP使えって事だわな

本質わかってないのは、何作ってるんだろうね？
人に作ってもらって喜んでるガキレベルかもね

>>258
本質ってなに？ ちょっとここに書いてみて

上から下まで、そしてまた上まで順を追って何をやってるか知れ。

ブロック図とかながめて終わってる口かな
資料あっても必要なとこも探さない読めない系の人が増えてる？

>>259
229,233

TCP使ってもIPパケット断片化が原因の問題は起きうる。
(ill-functionalなhostは経路上にいないと仮定しても)
そしてTCPスタックが馬鹿だと、自分では解決しづらいことがある。

どういう時に起きうるかというと、
ルータの次の経路のMTUが極端に小さいのに、
fragmentationの実装は必須でないので実装してない場合。
(reassemblyの実装は必須)

まあ要するに十分小さいパケットを送っていれば気にする必要はない。
TCPスタックが行なっている解決方法は、
"Fragmentation Considered Harmful"を。
UDPプログラマはこの程度の内容は知っておくべき。
LAN内でしか使わないなら、なんちゃってプログラミングでいいと思うが。

>>262
それがキミの考える「本質」なの？

>>264
君の答えは？

聞いておきながら自分が納得しないと怒ったり否定したりする愚者がいる
人に説明を求めて解答が常に得られると思っている蒙昧な者も多い

仕様がわかんないのでどうしようもない

　 　 _, ,_ 　ﾊﾟｰﾝ
　（　‘д‘）
　　⊂彡☆))Д´） >>267

>本質わかってないのは、何作ってるんだろうね？

ここで言う「本質」が何を指しているかわからんから、この文自体が
何を言っているかわからないというだけだろ？
別に何か意味があるわけじゃなくて、なんとなくもっともらしい台詞を
書いただけなのかも知れんが。

いたたた、なんでやねん

俺は、本質わかってるだぜぇ。

って言いたいだけだろ。

ここまでのレスで内容が具体的に書かれてないところ見ると、本当かどうかは
かなり疑わしいから、普通にスルーでいいんじゃね？

>>271
君は質問者か？

具体的な内容書かれても理解できないからスルーしましたって話だね

もしかして、一連の意味不明なレスはみんな>>181なんだろうか？

>>273
そんな事は、その具体的なレス番を示してから言うことだよ。

>>275
スルーしたレス番を示してみな？

俺) 具体的な内容書いてるレスがない
>>273 理解できないからスルーしたんだろ
俺) 内容書いてあるレス番書きなよ
>>275 スルーしたレス番示せ

ひょっとして、馬鹿なの？

まあ、やっぱ脳内レスでしたというオチなんだろうな。

>>277
スルーしたレス番を示してみな？

結局それしか言えない訳ね。

それがわかれば十分、相手にした俺が馬鹿だったよ。

今のnat前提インターネットでは当たり前になってるけど、なんでもかんでもtcpで送っとけば良いってのは違うと思うけどな。
udp要らないじゃない。

まあインターネットでudpで送ってもまず届かないから、lanやネットワーク管理者の管理下にある社内lan程度に留めとけってのは分かるけど。

届く届かないとUDPかTCPかってのは関係ないだろ。
途中のreouterであえてUDPをブロックしたり優先度を下げているとかじゃなけりゃ。

あいかわらず、馬鹿の突っ込み

突っ込まれまくってる本人か？反論があるなら具体的に指摘してやれよ。

いいや、馬鹿は馬鹿

>>283
283=281?

>>282
どのあたりが馬鹿なのか、解説してみろ。

>>286
君のレス番は？

>>287
>>281

>>288
そこだけつっこんもしょうがねーだろ

馬鹿の壁

じゃあ残りはお前が突っ込んでやれよ。
馬鹿にはできない突っ込みの手本というものを見せてくれ。

なにこのグダグダな流れw

元の質問者はまだいるのか？

たぶん上でいろいろ突っ込まれていた奴が、反論できないけど
くやしいから何か言い返したくて「馬鹿」と言っているだけ。

Linuxのプロトコルスタックの性能はどうなの？
昔はFreeBSDの方が1.1倍いいと言われていたが

>>294
今はFreeBSDの1.2倍いい

ちなみにWindowsは33倍いい

>>295
根拠はある？

最近はプロトコルスタックの多くの部分がEthernetのチップ上で動いている@Windows

ぶっとんだのか

iocpで組む腕があるならwindowsでもいいかもな

UDPホールパンチングの説明ってポートを開放していないクライアント同士の例ばっかりだけど、
ポートを開放しているPC-Aとポート未開放のPC-Bがあるとき、

1）B→Aに送信
2）Aは受信後、送信元（B）に送信
3）Bが受信

としたとき、2〜3番のA→BについてもUDPホールパンチングによって可能となった
と考えていいのかな？

君がどう考えてもそれは自由だよ

「2〜3番のA→Bについて『も』」と言っておるが、
(1)についてもUDPホールパンチングによって可能となったと考えているのか?

まさか日本語の使い方についていちいち突っ込みくらうとは思わなかった
>>302
「も」は一般的に例に挙げられるポート未開放のクライアント同士の通信に対しての「も」だよ

日本語のwikipediaじゃなくて英語のwikipediaを読むと良い。

> UDPホールパンチングの説明ってポートを開放していないクライアント同士の例ばっかりだけど、

でないことが分かる。

無線APへ複数のAndroidを接続。Androidアプリ（Java)

IPMｓｇみたいなことをやりたくて、
１．A機種でServerSocketを待受て、AからUDP送信
２．B、C、D機種で受信
３．B、C、Dで受信したパケットオブジェクトから、Aのアドレスを取得して、
各機種からAのServerSocketめがけてTCP接続
　→　エラー発生（することがある）

結果、
・B、C、Dすべてで、応答成功
・B、CはAへ応答を返せたのに、DでだけNo route to hostが出る
・Dは成功したが、B、CでNo ｒｙ〜

みたいな症状が出ています
タイミング的なもんか？とは思うんですが、なんかよくわからん

・No ry〜が出るときは、DからAへのpingコマンドでnetwork unreachable、
・AからDへpingすると、接続が回復する（ように見える。次回アプリ実行時にNo ry〜が出ない）
・Dからarp who-hasのブロードキャストが出ているが、Aで受信せず、B、Cでは受信できている

stackoverflow.comでAndroid + No route to hostって質問がいくつかあるけど、
結局解決してないように見える

なので、２ｃｈで解決するべ

wireshark でみたら？

ハッカー財閥　会長　トップは masa
ジャッチメント（規律委員）は全員しておくこと　1円でしておくこと
最新情報　大金をすべてしておくこと　
下に、無限超を数字にして、沢山書いて、数十枚、数百枚、数千万枚、数千京京京にして、銀行や松井証券など
に提出、FAXすればいいよ。上に京万枚と書いておくこと
最新情報　大金　
http://sky.geocities.jp/mannga9999/keizai2.txt
経営板で、アイスクリーム屋と、クリーニングの板見ればいい。
ほい。　
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
あとは、財閥の登記するだけ。kore
これノウハウ。教えていってたから、教えたおん。よ。
まーちゃんに、募金すること

突っ張りすぎて、中国の元が無価値になっぞ。実態のない経済は滅ぶ　今、元はマイナス。
http://blogs.yahoo.co.jp/mymymy90jp/2857425.html

これ改造して、大富豪ソフト作れない？金のレートが下がる時は、レートも下がるので、落ちる角度を計算してＭその前にもどす機能があると、世界不況のときにも、できる。
http://www.vector.co.jp/soft/dl/win95/business/se312001.html
探せば、ソフトあるよ。瀬谷貴文が完成させている。
絶対命令
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
masaの分もやっておくこと　
depend　on　銀行、matuisyouken　monex
最後に、福祉財団、貧しい人を助ける財団をつくること
絶対命令　DC

コピペマン参上！まで読んだ。

sendtoとreceivetoでPC間でデータ受け渡ししてます（１回950バイト程度）
送信間隔は50msくらいなんですけどたまにパケットがロストします
特にsendtoはエラーを吐くわけでもなく普通に通信を続行してます
１時間に０から２回程度ロストする現象が起きます
このようなことはUDP通信では普通なのでしょうか？
なんとかロストしない方法があったら教えてください

普通でしょう
ロストしたらもう一度送ればいいと思います

IPv4 の仕様がよくわからんのですが
パケットヘッダのチェエクサムってのはルータを通るたびに変わるんですかい？
他にルータを経由してパケっどヘッダの中身で変わる可能性があるのは
Type of Service, TTL, Header Checksum, Option　であってます？

IPv4の仕様読めばすむ話だろ低脳

>>309
UDPはロストするもんです嫌ならTCPを使いましょう。
１：１の通信でUDPを使うメリットは殆どないと思いますけど。

>>313
ど素人がアドバイスするのは100年早いですよ。

>>311
NATとかフラグメントとか考えれば
もっといろいろ書き変わるけど。

あるだろ。バカ。
マルチキャスト/ブロードキャストよりユニキャストの方が圧倒的に
多く使われている。

>>313
STREAMとDATAGRAMの差も理解できないバカですか？

UDP(ﾃﾞｰﾀｸﾞﾗﾑﾍﾞｰｽ だけど、ロス有)
TCP(ｽﾄﾘｰﾑﾍﾞｰｽ だけど、ﾘﾄﾗｲ等である程度保障)
中間の SCTP ってのがあるけど…　まだまだ普及してない印象

ある程度保障されたﾃﾞｰﾀｸﾞﾗﾑのやり取り　という用途は悩ましい
UDP でﾘﾄﾗｲ機構を考えるか, TCPでﾃﾞｰﾀｸﾞﾗﾑ単位に切り出す機構を考えるか

>>309もド素人だから、
>>313の一行目はいいと思う。
2行目は間違い。

使う必要ないところでUDP使って勝手に泥沼に嵌る奴が多すぎて笑える

>>319
いいえ、50ms間隔で送信という要件が出てきた時点で
TCPが候補に挙がることはあり得ません。
１行目も誤りです。TCPの再送機構にだけ目が行き、
それによってどのようなパケットフローになるかがまったく
考慮されていません。

>>315
逆に言うと
そのあたりがなければTOSとTTLくらいってことですか
ありがとうございました。

無知どうしで罵りあいわろた
全く解決できてないしｗ

>>321
PSHフラグあるがな。

50msってどんだけ長い時間だか分かってる？ｗｗｗ

>>323
> なんとかロストしない方法があったら教えてください

そりゃこれが直結しない限り解決不能だし。

50msを長いと思ってしまっている人がシステムを設計すると
すごい結果が待ってる気がするｗ

直結でも同じなんだけどな

どんな環境（OS、ネットワーク）なのか、50ms毎に送信するデータサイズが何も書かれてないのでアレだけど
50msがTCPじゃだめでUDPならOKという判断がどこから出てくるのかと

しかも
> なんとかロストしない方法があったら教えてください
の要件で

書き間違えてすみませんが実際は20msごとに950バイトのデータを送信します
直結でやってますけど１時間に１回くらいでる頻度を
３時間に１回とかもっと頻度を減らすことは無理ですか？

>>309
回線上ではロストしていないことが前提だけど
SO_RCVBUFとSO_SNDBUFを増やしてみては？

> sendtoとreceivetoでPC間でデータ受け渡ししてます（１回950バイト程度）
データサイズがわからないメクラはレス禁止

>>331
OS、ネットワークHW、ドライバを厳選すれば頻度を下げることは不可能ではない

どこで消えてるか調べるのが先でないかい？

1パケット/50msか　楽でいいなあ

>>324
PSHの作用としては正しいけど、そういう使い方をするものじゃないよ。

色々ありがとう
使ったことないけどパケットキャプチャソフト使って監視して
ちゃんと受けてるのに消えてるならバッファ容量増やすってことですね
ちょっとやってみます

いや、どんだけ頑張ってもロストするから

>>338
netstat

1パケット/50msでロストするのは明らかにバッファサイズのせいじゃないし

>>331
以下のような、定遅延で高品質なシステムを設計すれば可能かもしれない
・リアルタイムOSを採用して、通信プロセスが途中でスイッチされない優先度を設定する
・コンピュータとネットワーク全体を電磁シールドで包み込む

それが無理なら、素直に>>313が言うようにTCPを採用しなさい

専用バスで直結するとかでなければ
100%ロストしない環境は構築できないよ。
SATAやPCIEですらパケットロスがあるんだぜ？

>>314
分かりました１００年後にまたレスします

>>341
50ms間隔で刈り取れることを前提にバッファサイズが950バイトに
なってるかもしれんｗ

1kバイト/20msなら2,3個送って重複したの捨てればいいじゃん。

>>331
20msごとに950バイトのデータを送信って何に使うのですか？
しかもロストしないのが前提って。

ハード屋さんはUDP使いたがるけどソフト屋さんはTCPが好きw

>>347
不明な用途では回答できないなら引っ込んでなよ。

>>339
良いこと言った

ロストを減らしたいってんでしょ
よく読まないメクラが多いな

1時間に１つは駄目で３時間に１つなら良いとは・・・

仕様に文句言ってしょうがない

一番重要な事は伏せられたままである。

>>321
1時間に１，２回再送するだけじゃないのよ？

>>321
ん？50msという定数を速い or 遅い、どちらで判断しているのかな？
こういった定数は前提環境によって基準が変わるから、まずそれを明確にしてほしいね

自分としては、>>309に「信頼性のある(=ロストしない)通信」という要件が出てきた時点で、
第一候補としてTCPを選ぶよ
どうしてもUDP上の独自プロトコルを設計する価値のある極めて限られたケースであれば、
ようやくUDP選択を検討し始める

>>344
馬鹿のつまらんヤジはスルー汁！！

IP接続にリアルタイム性を求めても無理ですよ。

さっそくしらべてみました。
Microsoft Network Monitor3.4で受信側PCを監視したら
パケットが届いていませんでした
これは完全にロストってことでどうしようもないですか？
まだロスト率下げる手とかあるんでしょうか？
余りプログラムを触りたくないのでUDPでやりたいんです

>>358
再送ロジックを実装汁よ。

またまたまたまた、この手のレベルの意味の無い言い合いが始まっちゃった

さっそく調べてみてこれだけの時間でロストが判明するなら、
1パケット/1時間より高頻度で発生してるって事じゃん。

夏休みの学生の釣りでしょう

>>356 が言うようにロスト不可な時点でUDPの選択肢はない。

再送ロジックといっても送り側はエラーも検出できないし
相手からの応答処理とかいろいろ追加してたら20msでの送信も難しくなるし
ロストは仕方ないとして頻度を減らすいいてがあれば…

>>358,364
まだ言ってるかwww

(>>358) >まだロスト率下げる手とかあるんでしょうか？
(>>364) >ロストは仕方ないとして頻度を減らすいいてがあれば…

>>334,342を嫁

>余りプログラムを触りたくないのでUDPでやりたいんです

前段の手段なら完全にハードウェアの話だから、プログラムは無変更で対応できる「かも」しれない
それが嫌なら、素直にTCPを使いなさい

>>359
プログラムをUDPベースからTCPベースへ書き換えるコストと
UDP上の独自プロトコルに再送ロジックを追加実装するコストを比較汁！！

>>364
無いでしょう。
直結ならRS-232C/422で良いのでは。

RS-232Cじゃ速度的に無理だったw

受信側がなにを期待しているか次第だな。
やみくもにTCP勧めてるのは宗教家か何かだな。

TCPの再送制御がどういうものか理解してTCPを使うならいいと思うけど、
TCPはロスが続いた時の復旧がね。
個人的には再送制御を簡単に入れ込んだUDPのほうがおすすめ。

TCPで再送云々になるならUDPで入れ込んでも一緒では？

>>368
アナログ的なデータならロストしたところを前後値から補完すればよさそうだしね。
用途が分からなきゃアドバイスもできない。

>>369
TCPの再発明にならなきゃ良いけど

再送はいらないけど抜けを少なくしたい、というのがね
環境によるだろうし今うまく行ってもあとで困るかもだし。
連番入れて抜けたらそこからやり直してもらう、とかでいいんじゃ？

>>369
20ms間隔で1時間送って１，２個のロスでしょ。
殆どACK応答で再送なんかないでしょ。

>>370
TCPはロスが続くとどんどん再送時間が長くなるんだよ。
ストリームだからその間データは送れないしね。
物理的に復旧してから再送時間の満了までが無駄。
順序性保証との兼ね合いだけど、UDPでガンガン送り続けて
届かなかった分だけ再送で送りなおしてもらうほうが俺の好み。

そんなの作りこんでたら管理するデータが増えまくって無駄。

>>373
１時間で1,2個のロスしか絶対にしないことが保証されているならね。
何用のプログラムか知らないけど、それが保証されているならいいけど、
俺は、何かの実運用に使われることを想定してケーブル抜けとかそういう
のを考慮してUDPを推してる。

>>375
そうでもないよ？
TCP並みにやろうとするとすごいことになるけど、
オリジナルの簡単な再送ロジックとか作っておくと、いろいろ使いまわせるよ。

色々すみません
厳密に言うと今は直結もどきなので本当のクロス直結でやってみます
これでロスが減るとうれしいんですが…
ちなみに現状の構成はこうなっています。
スイッチングハブだから直結と同じかと思ってますが違うのですかね？

PC（送信）---スイッチングハブ---PC（受信）
　　　　　　　　　｜
　　　　　　　　　モニタ用PC---(無線）---ルータ---(インターネット）

これを、以下のようにしてやってみます
PC（送信）---PC（受信）

余りプログラムを触りたくないと言う人に作りこめって本末転倒？

>>376
一方的にTCPで送ってTCPのエラーが返ってくるまでだと接続断検知まで
何分も待たされるけどね。普通は相手側からなんらかの応答が返るような上位プロトコルに
するでしょうし。

>>378
スイッチングハブって他のPCのパケットモニターできるの？

パケットモニター？

>>379
TCPにするにしても、それなりに手が入るんだから
まあどっちにせよがんばれってことで。

>>381
ミラーポートの設定ができる、高い奴ならば。

>>381
まぎらわしい書き方しましたがモニタPCとは受信側PCの受信プログラムを
コンパイルして受信PCに共有フォルダで送るだけのPCです
パケットモニタは受信側PCにMicrosoftのモニタソフトを入れて直接みました

相手局もPCで　それぞれのコードに手出しできるなら良いよなぁ

PC vs 三菱のPLC で、ﾌﾟﾛﾄｺﾙは相手側の事情で固定ってモデルで泣いた

外野がいろんなパターンを想定してあーだこーだ言っているのに
相変わらずマイペースで何が求められているかも明かさないレス主。

嫌なら見るな

>>378
最初の質問から空想してたネットワーク構成と全然違ってびっくりしたW

>>386
MXコンポーネント使わなかったのか

>>387
学生さんにそんなこと要求しても

>>389
全然違うってほど違わないだろ
スイッチングハブなんだからいらないパケットは通らないだろうし
直通と一緒じゃね

>>390
うむす。　MCﾌﾟﾛﾄｺﾙを直接おしゃべりしたよ

>>393
それは泣けるお話だな。いや、良く実装したもんだw

ポートミラーリング設定しても100%ミラーできるわけじゃないしなあ…

スイッチングハブがぼろいと輻輳が起きてパケット消えるかもね
直接続ならそれが起きる可能性ないからいけるかもな

>>392
まあロスト率が倍になる程度かもね

クロス直結で１時間以上何もロストしてません
ハブかケーブルが原因だったようですね
このまま、ロストせずに長時間継続できたら解決です
ありがとうございました

まだこんなことやってんの

て解決したか

な

ん

今後クロス直結で運用することで解決か

いまどきクロスもストレートもないけどなw

長時間試験した上で自分の責任で保証するしかない
誰も保証してくれないから

直結はクロスのみです
未だにストレートおｋになっていないはず

いまどきクロス/ストレート接続自動判別機能なしのスイッチ探す方が難しい。

PC-PC直結で、間にハブが居ない話ですので
PCのIFｶｰﾄﾞ側にクロス/ストレート接続自動判別機能が居るか？が焦点かと。

>>405
1000Base-Tなら、Auto-MDIは必須です。

>>408
1000Base-Tなんて誰も言ってないだろアフォ

>>406
そうそう。すごい苦労したわ。

自動じゃない奴なんて皆無に近い。PCも同じ。
逆に知らない奴はわざわざクロス探すか作ってたのか？

うちのサーバ機、オートのやつなんて皆無だが

ふつう、クロスアダプタくらい机の中に入れてるだろ

サーバーでGbEじゃないのって骨董品だろ。

リピータハブを買うのも苦労する時代だし仕方ない

一日で100レス伸びてるんだが何があった
ム板屈指の超人気スレみたいじゃないか

そもそも、20msの処理なんてWindowsでは無理ポなのだが

久々の大漁

>>417
コンピュータなんてナノで動いてるのに無知だな
100マイクロの制御プログラムとか何年も前に造ったことあるよ

>>419
Windowsで?

>>420
もち

>>421
へぇ〜、Windowsでそんな応答時間が保証されるんだ。。

パフォーマンスカウンタなら1ms以下の精度

1ms守ればいい ってのならWindowsの方が気楽に書けるね

WindowsってリアルタイムＯＳじゃないっぺよ〜

>>425
リアルタイムOS の定義知ってる？

Windowsの応答保証って25msくらいじゃないのさ？

WindowsはRTOSじゃないから、他のタスクが走っていて忙しい時には
保証するのは無理だろう。
当然、TCPでは無理だけどUDPなら大丈夫、という状況にはならないはず。

で、timeBeginPeriodかなんかで、20msより短くすれば
「CPUが忙しくなければ20ms以下の間隔で処理できる可能性が高い」くらいにはできるだろう。
当然だけど、TCPならばnagleも無効にしておく必要がある。

最近のマザーボードは、CPUクロックを動的に変更するからな。
パフォーマンスカウンタ信用できんだろ

RealtimeOS上で動くWindowsってのもあるんだぜ
勉強になったな

CPUクロックの変更と、タイマは関係ない。
タイマは、割り込みを発生させる、変動の少ないもののはず。

>>430
いくらすんの？

>>430
超マイナーじゃないですか。

>>430
そのWindowsはリアルタイムOSなのか？

RealtimeOSの意味が分かっていないのだから、そってしといてやれ

標準的なネットワーク（今だと1000BASE？）のレイテンシと
標準的なディスクのレイテンシって
今だとどちらも数msくらいで同等だけど、以前はどうだったんだろう？
ネットワーク速度の進化の遅さを考えると、昔はもっと差があったのかな

どうでもいいじゃないかそんな事

>>434
リアルタイムＯＳ上の仮想環境でWindowsが動いて
リアルタイム処理が必要な場合は本体側のＯＳを使う製品が昔合ったな。
今もあるかどうかは知らないけれど当時１００万くらいしたはず。

>>438
今もあるよ。
っhttp://www.mnc.co.jp/intime/

すげーな
50μで動かせるのか

pingで負荷試験もどきとかやらないのかね？

>>441
そんなんで何の負荷試験ができるのだ？

なんでやらないんだ？

>>442
NICへの高負荷

>>444
pingで？

>>445
ショートパケットは負荷高い

>>446
1パケット/1秒で? 負荷高い?

日本だとハッキング扱いされて逮捕されるぐらいには負荷高い

日本だとpingが不正アクセスになる

ダウンロードしただけで逮捕

>>448
DOSアタックってどんな容疑で逮捕？

>>450
○○なものをダウソするとでしょう

>>451
岡崎図書館事件で検索

大抵は不正アクセス禁止法違反でしょっ引けるからな
一旦しょっ引いたら監禁して自白強要の力技で終了

不正アクセス禁止法違反って、パスワードなどのアクセス制御を突破したり回避したりしなきゃ成立しないんじゃない
DoS攻撃はアクセス制御を回避する必要なんか微塵もないから、ただの業務妨害なんじゃない

まあとりあえず逮捕するんじゃないかな

とりあえず逮捕して、すったもんだのあげく訴えた側に非があったことに気づいても
体裁のために取り下げできないんだよな。

金子氏がどうなってしまったか

それどこの岡崎図書館事件

>>453
そりゃTCP TIME_WAIT が溜まって?サーバに接続不能になった
おそまつ過ぎるサーバアプリに原因があったのでは

その脆弱性を突こうとするのは不正アクセスと看做せる
故意か過失は当人にしか分からない、という事は取り調べでどうにでも出来るという事

>>460
1パケット/1秒のpingで高負荷試験している>>444のサーバに攻撃したら楽勝で逮捕。

不当逮捕は警察も罰せられるべきなんだけどなー

ゲイツ砲でurl間違えたら即逮捕だな

>>447
フラッドオプションでググれ

まあflood攻撃はインフラ設計時の話であって
プログラミングにはあまり影響はないけど
知らないってのはヤバイ

>>466
1時間に400アクセスで落ちる某図書館のシステムを作ったＳＥは?

まあ図書館のシステムとかど素人が作ってそうなイメージだなｗ
データつっこんで検索するだけだもんなｗ

まあDBの基本だしな

>>467
三菱なんとかってとこだったかな

C++やC#でネットワークプログラム作れますか？

何でその２つなのかわからんけど作れるよ、内容によるけど

Javaにしとけ

>>471
>ネットワークプログラム
ワームか

C++でMMO作ってるよ

>>471
作れない

ネットワークプログラムって単語で語りたいだけじゃね

boostのネットワークって作りこみ甘いよね

ネットワークプログラミング入門したいのですが何からやるべきなのかとんと見当がつきません
いい入門書はないでしょうか？オライリーの体で覚えるネットワークとか評判いいですけどどうなんでしょう？

まずはケーブル作りからじゃないか

>>479
スティーヴンスの遺作を読め

>>479
知ったかぶりする知識をつけるには良い本だと思うが駄本の香りがするし
そもそもプログラミングの本ではないでしょう。

>>479
>>3-4 見れ

猫でもシリーズは除外だ

イーサーネットプログラミングといえばTCPIPプログラミングのことでしょうか？
イーサーネットでファイルを送りたいときの一般的なプログラミングとかあったら教えてください
TCPIPプログラミングだとは思うのですが経験がないのでよくわかりません

イーサーネットプログラミングはイーサーネットをコントロールするプログラムであり一般的にはドライバの部類ですのでファイルを送るなどは関係ありません

>>485
先ずは通信プロトコルからお勉強してください。

TCP/IPはイーサーネットより上の層

ネットワーク層以下を触るようなプログラムなんてそうそうあるんですか？
VPNサービス作るならデータリンク層触らないといけないとかは聞いたことありますが

VPNだってほとんどがover IPの時代。

シリアル通信

確かにシリアル通信はだいたい物理層の直上で作業するな
つーか2〜6層がごっそり抜けていきなりアプリケーション層だよな

>>485
電気信号にプログラムをデコード・エンコードするのは結構難しい

パイソンで入門するとわかりやすい

>>493
>電気信号にプログラムをデコード・エンコードするのは結構難しい

それは物理層の責務だよ
そして、>>485の言うイーサネットはデータリンク層のプロトコルだ
素人はネットワークアーキテクチャから勉強し直しなさい
--> http://ja.wikipedia.org/wiki/OSI参照モデル

こういうめんどくさい人が、このスレから消えますように

>>495
汎用IFで直接信号コントロールする場合もあるんだよ。

ISOのOSIを知っていても実際は余り役には立たないな。
OSIは後付け理論なので実際とは合っていない。

>>497
釈迦や孔子が生きていた時代の話ですね。

>>499
でもたまーに今でも「手動で232c受信」をやることがあるよ！
助けて！

>>498
RFC読んだら分かるが、OSI参照モデルは既に常識になってる。
プロトコル階層をまたいだり、逆転したりする場合にも、
OSI参照モデルの言葉でそれが説明されてる。

OSIで死んだのはプロトコル群。CLNSとか。
ASN.1みたいにLDAPの中で生き残ってるエンコーディング方式もある。

>>500
UART買えないほど貧乏なのですか

>>502
基板を作り直すお金が無いほど貧乏

トークンリングてまだ動いているのかな

>>503
ソフト実装で38.4Kbps出せたら神認定で良いのか？

>>495
プログラムをデコード・エンコードつうのもよくわからん話だが
物理層の仕事はデータ（ビット情報）と電気信号との変換
そのデータがプログラムなのかどうかなんて関係ない
ま、>>495本人は解ってるだろうけど

>>485
とりあえずTCP/IPだけ勉強しとけば、そのへんは必要ならそのうち解る
必要ないなら解らなくても困らない

>>506
馬鹿乙

>>507
低脳乙

>>508
はじめまして馬鹿

>>509
池沼乙

>>510
506=495

とりあえず入門者はTCP/IPからでいいんですか？
ハードウェアの知識どころかOSの知識もほとんどないんですがそんなんでやって行けるんでしょうか
標準C/C++のコードが書けるだの能力しかありません

右を向いても左を見ても
馬鹿と阿呆の絡み合い

>>512
OSの知識なんて2chにレス出来るだけで十分。

>>512
> そんなんでやって行けるんでしょうか

ん？
ネットワークプログラミングの仕事でもやらされようとしてるのか？
とりあえず、どのOSでやろうとしてるかぐらい書いたほうがいい。

>>515
すいませんどのOSかはまだわかりません
来年からSEPGやることになったのですがなにがなんだかわからない状況です
金融系業務システム(社内ネットワーク？)と組み込みを中心にWeb開発もやってると言っていました

金融系業務システムと組み込み Web 開発？

ていうか、SEPG ってうちだとネットワークの設計までしかやらないけど、
一般にはネットワークプログラミングまでやるもんなのか？

来年からなら来年考えればいい

テンプレ見て本買って勉強しようと思えない奴はどうしようもない。

>>517
単なるWebアプリ開発だと思われますな。
おそらくネットワークプログラミングは何の関係も無い。
ドナドナ要員でしょうなぁ。ご愁傷様です。

ネトウヨ記念(画像あり)
http://www.shogakukan.co.jp/magazines/detail/_sbook_2300508112
http://www.shogakukan.co.jp/var/files/storage/images/node_43/node_61/node_122/node_128/node_132/node_184/sapio12/6524796-2-jpn-JP/SAPIO.jpg

>>517
たぶん、専門分野とか関係なくダボハゼのように仕事を取ってくる下請けなんだろ。

売るか売られるか。それだけだもんな、人月商売はｗ

MODBUS TCPてC#のTCPClientで送受信できますでしょうか？
ﾍﾟｰﾊﾟﾚｽﾁｬｰﾄﾚｺｰﾀﾞｰに流れてくるﾃﾞﾊﾞｲｽﾊﾞｽの瞬時値を
横から分捕りたいなと。

意味不明、エスパーカモーン

>>524
モドバス側がTCP Serverで複数接続可能なら出来るかも

ｸﾗｲｱﾝﾄがﾏｽﾀｰでServerはSlaveだったっけ？

>>527
それはMODBUSプロトコルの話かな？
TCPポートを開いて待機している方がサーバです。

>>524
通信用のミドルウエアないの？

ﾌｨｰﾙﾄﾞﾊﾞｽか・・・ 今は何処のﾌﾟﾛﾄｺﾙが主流なんだろう？

ＪＫプロトコル

>>530
世の中、HTTPばかりだろう

次の関数　opにある　変数宣言の欠陥とセキュリティホールを指摘せよという問題がわかりません。セキュリティホールは　rcv(sock, pkt->hd.sz, pkt->data);　のバッファオーバーフローだと思うんですが
変数宣言のほうはint fd; の初期化がなされていないためfd代入前に case OP_READを貰うと想定外のread();をしてしまうということでしょうか？

void op(int sock, packet *pkt) {
　int fd; // declaration 1st
　int n = -1; // declaration 2nd
　switch (pkt->hd.cmd_or_stat) {
　　case OP_OPEN:
　　　rcv(sock, pkt->hd.sz, pkt->data);
　　　pkt->data[pkt->hd.sz] = 0;
　　　fd = open(pkt->data, O_RDWR);
　　　　if (fd > 0) pkt->hd.cmd_or_stat = SUCCESS;
　　　　　else pkt->hd.cmd_or_stat = FAIL;
　　　pkt->hd.sz = 0;
　　　break;

　　case OP_READ:
　　　if (fd > 0) n = read(fd, pkt->data, 512);
　　　if (n < 0) {
　　　　pkt->hd.cmd_or_stat = FAIL;
　　　　pkt->hd.sz = 0;
　　　} else {
　　　　pkt->hd.cmd_or_stat = SUCCESS;
　　　　pkt->hd.sz = n;
　　　　}
　　　break;
　　case OP_CLOSE:
/* the following code is omitted. */
　}//end of swith()
}// endof op()

ローカル変数は関数を抜けたら消えるから OP_OPEN で呼ばれたときに保存したつもりの fd は次に OP_READ で呼ばれたときには消えている
セキュリティホールは俺の予想では open するファイル名じゃね
仕様不明ゆえに確かなことは言えんけど、
例えば sock から /etc/passwd とか受信してもそのままオープンしちゃっていいんかね
まぁ実効ユーザを適切に隔離してればいいのかもしれんが

rcv() って？

snd, rcv は送信、受信メソッドです

>>533
2つの問題以外にも突っ込みどころまんさいだな。

>>537
これの８ページのか。
東大だよw
http://www.i.u-tokyo.ac.jp/edu/course/cs/pdf/2009computer.pdf

op() の所だけ貼り付けられてもわからんな

/* the external declarations are omitted. */
typedef struct header {
　int cmd_or_stat;
　int sz;
} header;

typedef struct packet {
　header hd;
　char data[512];
} packet;

void mainbody() {
　int sock;
　packet pkt;
　sock = getConnection();
　while (rcv(sock, sizeof(header), &pkt)) {
　　op(sock, &pkt);
　　snd(sock, sizeof(header) + pkt.hd.sz,　&pkt);
　}
　closeConnection(sock);
}

なんつーかダメプログラムの見本みたいなコードだな
バグを別にしても

>>541
東大大学院入試問題なんだが・・

東大（）

>>542
それがどうかしたのか？
誰が作ってもダメなものはダメだよ。

ここまで具体的に駄目な点が指摘されていない、いや指摘できなくて単に駄目よばわりして鬱憤を晴らしている件について

回答者を悩ませるためにあえて無意味にややこしい書き方をした可能性もある

>>543
最近2chで○○()を良く見かけるけど『()』ってどういう意味？

>>547
中身空っぽわろすって意味

>>545
> ここまで具体的に駄目な点が指摘されていない、いや指摘できなくて単に駄目よばわりして鬱憤を晴らしている件について

>> char data[512];
>> if (fd > 0) n = read(fd, pkt->data, 512);

512 なんて書く奴今時いないんじゃね？

>> while (rcv(sock, sizeof(header), &pkt)) {
>> rcv(sock, pkt->hd.sz, pkt->data);

rcv( ) の戻り値を使っているところとそうでないところがある。

あと、op( ) 内の n の初期化と、実際に使っている case OP_READ: の間が離れすぎ、
初期設定は case OP_READ: 内でやったほうがいい。

>>548
それ考えたのLisperの仕業かな

() ⇒ NIL 空っぽ

>>549
rcv()には戻り値ないけど

>>549
重箱の隅乙

>>551
戻り値ないなら while( ) 内で使っちゃダメでしょ。

想像だが、読み込んだバイト数を返すようになってて、相手が切断したら 0 を
返すようになっているんだと思う。

つまり、ヘッダー読み込んだあとにいきなり切断される状況を考慮していない。
まあ、問題だから、それぐらいはいいかと思うが。

>>552
どこがダメか指摘しろって言うから指摘したら、重箱の隅とか。
出来ない子の典型かよ。(w

>>553
設問にrcv()の戻り値についての記述がないなw

>>553
rcv()は常に成功するとある。

>>555
うん、だから >>553 に書いた想像の域は超えない。

>>556
あるけど、それが何か？
Linux とかの recv( ) で、-1 が返ることはないよ、ぐらいの意味だと思う。

おいおい、
>>545 が問題作成者だったらまんまと釣られてしまったね。

別にこれで問題がより洗練されるなら、いいと思うぞ。

学生の宿題(?)と分かって誰も真面目に答える気がないなwww

>>533-534 以外にあると思うなら、書いてやれよ。

大学の教官が書くコードだから、このレベルでも通用するんだろう。
昔、某メーカで研究所で開発されたプロトタイプを製品化するプロジェクトに関わったけど、
最初にやったのがコードの整理だった。奴等、確かに技術力はあるけど保守とか考えていないからね。
>>538にはソフトウェア科学専攻とあるし、こんなもんだと思う。

>>549の指摘が重箱の隅(>>552)とか不真面目(>>560)とか言ってるのも学生さんなんだろな。
それでもいいだろうし、社会人になってから勉強して体で覚えるしかない気がする。

ダメプログラムの見本と言うほどじゃあないかと。

オープンソースも似たようなもんだけど

良くないものだったから問題に使ってさらし首にしてやったってこと？

>>547
(笑）から笑を取り除いて失笑って説を見たことがある

>>565
その可能性もあるなw

>>540がダメプログラムな最大の理由、それはエラー処理を考えていないこと
関数op()はvoid型でopen()/read()システムコールがエラーになった場合、
引数の構造体メンバ pkt.hd,cmd_or_status へFAILを設定するけど、
その値をメインループ内で参照していない。これはop()が戻った直後に検査してループを脱出すべき。
また>>538によればファイルサーバとあるから、errnoを参照して適切なメッセージをsyslog等へ保存すべき。

結論としては、学校のお勉強や試験問題であれば許されるけど、仕事で書かれたコードだとしたら
>>549の指摘を含めてダメダメプログラムだと断言する。
たぶんコードレビューだと、最初の5分で中断して再レビュー要と判定されるレベル。
レビュアーは「こいつもやっぱり学はあっても使えない(=即戦力にならない)」と心の中でつぶやくだろう。

問題用のプログラムでエラー処理とか、馬鹿じゃね？

> 引数の構造体メンバ pkt.hd,cmd_or_status へFAILを設定するけど、
> その値をメインループ内で参照していない。これはop()が戻った直後に検査してループを脱出すべき。

クライアントに返してるだろ、勝手に仕様作るなよ。

５分で、「頓珍漢な発言するなよ、うぜー」と他のレビューアから思われるタイプだな。

もっと重大な誰が見てもわかるセキュリティホールがあるのにね

へー、そーなーんーだー (棒)

getConnection 関数は、クライアントからのTCPコネクションを確立し、そのコネクションに関連づけられたファイルディスクリプタを返す。
closeConnection関数は、引数で与えられたファイルディスクリプタに関連付けられているコネクションを閉じる。
snd およびrcv 関数は、送信、受信関数であり、
第一引数にコネクションに関連づけられたファイルディスクリプタ、第二引数に送信あるいは受信バイト数、第三引数にデータのアドレスを与える。
これら4つの関数実行(getConnection, closeConnection)は常に成功すると仮定する。

open(ファイル名)　return ファイルディスクリプタ、　失敗時　-1 を返す。
read(ファイルディスクリプタ、格納先メモリアドレス、データサイズ）　return　読み込んだサイズ。失敗時 −1を返す。

>>569
>問題用のプログラムでエラー処理とか、馬鹿じゃね？

>>568では「試験問題であれば許される」と書いてあるけどな。

>クライアントに返してるだろ、勝手に仕様作るなよ。

クライアントへのエラー応答とは別に、サーバプログラムとしての適切なエラー処理を検討すべき。

>５分で、「頓珍漢な発言するなよ、うぜー」と他のレビューアから思われるタイプだな。

このくらいの指摘でウゼーと感じるようだと成長できないよ。
まあコード品質に関する基準がその程度の組織なら、厳しいと感じるかもしれないけどね。

東大入試問題よりネスペの問題のほうがむずいよ

>>573
しかし、>>540の適切なエラー処理ってどういうのを想定してるんだ？
仮にエラーを検知してwhileループを抜けてエラー処理したとして、
それが仕様で期待される動作なのか？

あと、これも試験問題であればどうでもいい話だけど、パケット形式仕様に相互接続性のバグを抱えているね。
ローカルなプロセス間通信であればC言語の構造体を直にパイプやソケットへ流すのは普通。
でも、ネットワークであればCPUアーキテクチャ(エンディアン)やコンパイラ仕様に依存してしまう。
ちなみにUNIX標準のNFS(ファイル共用)では、XDRとよばれる環境非依存な形式が使われている。

そんなもん実務では無視するだろボンクラ
俺知ってるアピールするとかパーかおめ

>>576
>ローカルなプロセス間通信
とローカルでない通信を同じに議論してるの、あほちゃう

>>575
すでに>>553-557で指摘されているけど関数rcv()の仕様が曖昧だから、何とも言えないw
もし成功の意味がC言語の真(0以外)であれば、プログラムは常に無限ループするから問題外。
もし>>553が想像したようにクライアントがcloseしたら0を返す仕様だとしても、
今のままだとエラー応答パケットを送信してコネクション切断が検出されるまでの時間、
サーバプロセスはコネクションに縛り付けられたままになる。
この振る舞いが正しいか否かはプロトコル仕様が提示されていないから、これまた何とも言えないw
ただし、一般的には回復不可能なエラーであればエラー応答パケット送信に続けてソケットをクローズし、
次のサービス要求の受付けを待つのがサーバとしての正しい動作だと(個人的には)思う。

op()のエラー処理じゃなくてrcv()の話だったん？

>>577
>そんなもん実務では無視するだろボンクラ

え、実験とか趣味なら無視というのなら分かるけど、実務で無視しちゃうの？
もしかして私は異世界の住人だったのかしら....w

あと、XDRは古い規格で(ほぼ)UNIX限定だからNFS以外ではほとんど使われていないけど、
今の時代ならProtocol BufferやMessagePackみたいに(比較的)手軽な実装が存在するから、
怖がらずに一度挑戦してみることを薦めるよ。

>>578
そのローカルなプロセス間通信とローカルでない通信とを同じ感覚で考えていたのが
出題コードを書いたプログラマで、>>576では「その考え方は間違っていますよ」と指摘している。
日本語読めますか？

>>581
しらんがなー

時代はASN.1

>>581
実務なら逆に、「サーバーとクライアントの環境合わせるからオッケー」てなもんだろ。

>>584
それが通用するような案件しか関われず、しかも問題意識を持たず実務をこなしていたとしても、
それはそれで本人のエンジニア人生なんだから、まあいいんじゃね........

要は実務じゃ原理主義的なべき論じゃなくて目的を達成できればいいってことだろ？
異種環境での移植性が要件にあればそうするだろうさ。

もともと面白くないお題だったが、ここまで落ちるともう停めるべき。

未だにセキュリティホールの具体的な指摘は全く無いが。

入力をpacketにつめてpacket.dataをチェックせずそのままopenに渡してるから
サーバが想定していないファイルにアクセスされる可能性がある
chrootしてあるとかサーバの権限上問題ないといった断りがなければ
セキュリティホールといって問題なさそうなものだけど

>>534

>>573
× このくらいの指摘
○ 頓珍漢な発言

東大ってこんなレベルが低いプログラム組むの？

>>565

恥ずかしい奴大杉

　　　　　　　　　　　　／￣￣￣ ｀＼
　　　　　　　　　　　/：＼＿__从＿＿ヽ
　　　　　　　　　　　i：：/　''''''　　'''''''　i
　　　　　　　　　　　|：/ ／ﾟヽ　 ､／ﾟヽ|　　このスレ、癒されるなあ。。^^
　 　　　　　　　　　(6　　　 ,ﾉ(､_,)､ 　 |
　　　　　　　　　　　ヽ　　　 ﾄ==ｲ　　ﾉ
　　　　　　　　　　　　 ＼＿'Uﾆ´_,／
　　　　　　　　　　　　　／　　 ／
　　　　　　　　　　　／　　　／
　　　　　　　　　／　　　 ／
　　　　　　　 :/　 　　　　 ヽ:
　　　　　　　:/　　　 　 　 　ヽ:　　皆さん、グッジョブです！
　　　　　　 :（ *‘ω‘*)*‘ω‘*):
　　　　　.／　　　　　　　　　　＼,
　　　　 /　　　,　　　　 .　　　　、 'i
　　　 ./　　　ｒ´　　　　人.　　　 ヽi
　　　 i　　　人_,､＿_ノ　 ヽ､＿,,_ﾉ.|
　　　 |　　 /　　ﾟ　　　　　　　　ﾟ .|.|
　　　 | 　/(　　　　　　　.з　　　.iﾉ

説明用に簡略化したコードが鬼の首になるとは…

http://jp.reuters.com/article/topNews/idJPTYE87N03W20120824
東証で７日に生じたシステム障害では、ＴＯＰＩＸ先物やＪＧＢ先物など
東証が提供しているデリバティブ商品のすべての取引が停止した。
東証のシステムは、稼働中の機器が故障した場合に予備機に切り替わる仕組みに
なっている。２月の障害ではこの切り替えがうまくいかなかった反省から
システム総点検を実施し、稼働中の機器の電源を切って予備機への切り替えを
確認していた。しかし８月の障害では、稼働中の機器の一部で不具合が
生じただけで機器自体の稼働が停止しないうちに予備機が稼働したため、
機器間の通信が混乱する事態になったという。

家電屋で売ってる市販ルータとL3スイッチってどう違うんですか？

>>598
家電屋で売っているルーターと名乗る物は、殆どの場合ルーターではなくNAPTサーバで
ルーターとしての機能は極めて限定的。

ルーターとL3スイッチは機能的には同じものだが、ハードウェアで処理するものがL3スイッチ、
ソフトウェアで処理するものがルーターと名乗っている事が多い。

機能は限定されているがrouterには違いない。というか、NAPTは
L3で動作する以上、必然的にroutingの機能が必要。

・家庭用routerのほとんどはWAN側とLAN側の2ポートしか持たない。
　(一部、DMZ用ポートを持つ製品もある)
・それぞれのポートはあらかじめ用途が決まっていて、対称ではない。
・ほとんどすべての製品でNAPTを搭載する。多段NATを検知して
　自動的にNAPT/routingを停止する製品も存在するが、明示的に
　NAPTを停止できる製品は少ない。

ソケットプログラミングについて質問があります。
UDPでjpegの画像ファイルを転送したいのですが
どうすればいいのでしょうか？
ちなみに言語はＣです。
よろしくお願いします!

速度目的でUDPを使うな。

こっちで質問するなら、C言語の方にちゃんと書いとけよ。

あと、速度重視で UDP とか言うなら、こっちにも書いとけよ。

UDPは垂れ流しの無手順だから、早いってだけなの
送信データが相手に届くかどうかの保証がない分

色々とすみません。
速さが一番重要なのでそこは
かまいません。
jpegをバイナリデータとして転送する
方法が知りたいんです。

速度目的でUDPを使うな。

その程度の事なら、netで探せばサンプルみたいなのはいっぱい見つかるでしょ
自力でやってみないと、UDPがどういうものなのかはわからんかもね

> UDPでjpegの画像ファイルを転送したいのですが

tftp でも使っとけよ。

お前にはプログラミングは無理そうだし。

>>605
> 速さが一番重要なのでそこは

じゃあなおさらTCP使え。
まだまだUDPで早い転送プログラム書くのは無理。
10年くらい修行してから出なおせ。

受信でもなく送信でもなく転送ってところがミソなんですよきっと

ttp://srgia.com/docs/rfc768j.html
これでも、ながめてみたら、速度重視君は

そうですね。
自分でもうすこしやってみます！

TCP,UDPの違いは分かっているつもり
です。
最終的には、画像を連続的に転送して
画像処理を行う事を目標にしているので
リアルタイム性を重視してUDPをチョイス
しているだけです。

connectしてsendするだけだろ

ローカルでやるなら、UDPでもいいかもね

> TCP,UDPの違いは分かっているつもりです。
やってるうちに、ハマりましたって、オチになりそうな

わかってないからみんなに突っ込まれてるのにな。

知識不足で申し訳ないです。

TCPとUDPの選択としては、
目標の早さを実現できるなら
どちらでもいいんです。
ただリアルタイム性という点では、
UDPに分があると思っただけです。

一度、両方試して比較してみたいと
思います。
色々とアドバイスありがとうございました。

人の話を聞く気が無いなら初めから質問するな

>>614
ローカルで行うことを想定しています。
ありがとうございます。

音声データなら、データ抜けしても、それなりに、復帰できるんだけど
jpegだとフォーマットにその手の仕掛けがあるんかね

想像するにFAXみたいなことをやろうとしてるのかな？

>>619
いえ、どちらかといえばストリーミング動画配信
のようなものを実現したいと考えています。
画像処理する上で画像の方が扱いやすいので…

パケットが届かないかもしれないだけじゃなくて
データが届く順番も保証されてないから
jpeg受信して表示したいとしたら面倒

好きにやらせてやれよ。

そうですね。
色々考えてるとUDPだと
厳しいかもしれませんね。
やはり皆さんが言ってる通り
TCPでやった方が良さ気ですね。

個人的にはUDPは、TCPと実際にどう違うのか
比較してみたくなりました。
色々とありがとうございます！

>>620
ローカルで実験的にやる分には、UDPで出来ることだよ、それは
WANでやると、ボロボロになる可能性大のような

jpegじゃなくでストリーミング向けの画像フォーマット
探すなり、考えるなりしたほうがよくね

直結 gigEｶﾒﾗの映像転送でさえ、かなり苦労してるっぽいのに…

>>624
WANどころか、UDPでやると転送が２つ開始しただけで、かなりややこしいことになる。

は？

うん、ややこしくなるな

音声と画像を同じパケットにしてみるとか
UDPで１パケ512バイト以上に出来るなら

受信側でパケットが来なかった時の補正が出来るようにしとけば
UDP２個使いも出来るかも

パケロスやパケ順入れ替え〜再生側時刻との乖離が激しくて実質ロス扱いの時の対処が問題

過去からの予測で済ますのか、再送するのか、ロスでほっとくのか

再送してたらTCPとほとんど一緒だからな
ロスは放って置いて補間なり無視なり

そういえばWinnyの人の会社がUDP上に速いTCP的プロトコルを作ったってのをどこかで読んだ

遠回りに見えるかもしれないけど、RTPがどんなことをやってるかとか
調べてみるのがいいんじゃないの？

へー、遅延時間の計算の仕方まで書いてあるんだ、解説ページ

　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

rm r,　　　　　　タマの裏までしっかりね〜！　　　　　.なわ┌─┐
.ヾ_｀ヽ　　　キ　　　　　　　　 　 　 　 　 　キ　　　 /),;彡んた | .ち│
　　＼＼　　 ャ . ,、　　　 ,.-─‐-、　　　 ャ 　 　 l ,- /　でし│ん .!
　　赤＼＼　 ッ　!｀ー--/ /´｀´｀ヽ　 　 ッ　 　 ／／ 聞もた | .ち│
　　ち.　 ＼｀ー､__.｀ー-i /　∩ ∩ |　　　　,.-‐´／　　い　ち...| .ん |
. 　 ゃ　 　 ｀-､＿ ７´｀ヽ|　 r─-, .|_,.-,.-´ ,.-‐´ア　　て　に.└─┘
　　ん 　 　 　 オ Y_　　　ト､_ヽノ /　　|_,-´　　ハ　 　ね
勃 も .＿＿　　ホ　ヽ　/ |＿二| |_,.-´　　 ＿_ハ 　 　！
起　 /;;;;;;;;;;;;;;ヽ ホ　 |ノ　　　　　 |　　,.-‐´:::::::::ヽ_　大な怖 あ洗皮
す　/;;;;;;-‐´｀ヾ;_,.-‐´　　　　　　/　/::r‐-::::::イ:::::::i 丈.く.が げっ を
る . {;;!　＾ L!^　|　　(⌒)　　　　(ll　(::::|の へ/::::::::::}夫て.ら て.て.む
の　ヾ､_ ﾉ▽　/-､-ｲ　|　　 　 ._||_っ｀| く_　 )::::::::::::}！も　　！　 .い
よ　 ./ ヽT二T|／ イ　|　　　 (ミ　/　.＼┘人,--､/　　　 　 　 　 て
∫　 |　　|　　/ ／ー-´　　 　 ヽ /　　　￣| /　　 ヽ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　 ＿　 i⌒i　　　　い 拭　　　 ＿＿　　　ま　う　　　　　　┌─┐
　　　.ﾄ;;;;;i.く ：.|　　 　 い け　　/´　　　＼.　 ぁ　ん　　　　 　 .| .ま..|
　　　 XT　 !.ノ　　　　か ば　 .|⌒⌒ヽ　 |__　：　　ヽ＿＿ . 　 | .ん |
　　　i7N_　　　　　　　ら　　 　 |,-､,-、|　人ヽ　　　/::::::::::::l 　 .| .こ .!
　　　7_N　　　　　　　　　　　　 ヽー　 |./　 ヽ!　　(:::::::::::::/|　 └─┘
￣￣|/ヽ|￣￣￣￣￣￣￣￣￣７--ｲ/＼￣￣￣/ー,-|ﾉ￣￣￣￣￣
　　￣ ￣　　　　　　　　　　　　　/ー┘!　 .〉　　　/　/|　ヽ,,/｀丶、
　　　　　　　　　　　　　　　　　　(　　　 | Y |　　　.|／ .|,-くヽ-‐､/
　　　　　　　　　　　　　　　　　　 |　　　 | | .|　　/f　　 | r‐Y二/───
　　　　　　　　　　　　　　　　　　 |　　　 ヽ./　　| .|　　 | ト､＿＿＿＿＿
　　　　　　　　　　　　　　　　　　 |　　　　 |　　 .| .|＿__l .!　 |

>>631
再発明しなくても、RFC-3350にRTP(A Transport Protocol
for Real-Time Applications)ってのがあるから、
真似したらいい。

MDPは

たまにUDP使うくせにデータの遅延や欠落を考慮して再送やチェック入れまくった結果TCPの劣化版作ってる知能障害がいるけどあれは何ですか？

またUDPか
ホント後を絶たないねこの手の勘違い

UDPってどんくらい早いの？

はやいわけではない

>>640
SCTPを教えてやれ

>>638
流し読みしたけど、NTPと同じような方法で遅延計算できるしくみが内包してるのね
なかなか興味深い

FA用途の汎用ﾈｯﾄﾜｰｸﾌﾟﾛﾄｺﾙって今は何が一番高速なんすかね？CC-LINK IE？

距離とか数とか接続元/先とか考慮しなきゃならんのじゃないかね

高速ってのもなんだかな

>>646
>FA用途の汎用ﾈｯﾄﾜｰｸﾌﾟﾛﾄｺﾙ
なにそれ、すれちそう

て言うか、○○用途 の 汎用 って矛盾してないか？

無手順だから早いってだけで
やり取り入れりゃ、ものによっては遅くなったりするわな、UDP
TCP使っても、相手がだんまり決め込む可能性があるってのが味噌

TCP使ってるのに、相手が無応答の時は再送処理をしろ
という仕様を突きつけられた。

要件によっちゃあ、それが必要な場合もあるだろ？

APとプロトコルレベルは違う

とまじれす

>>652
やれば、良いんじゃね？

TCPにおける再送処理は接続からやり直せば意味あるし、
実際におれも一定時間内に応答が無ければ接続からやり直すって
処理は良く作ってたよ。

>>655
接続しなおせば当然意味あると思うけど
そのままやれって意味わかんないよね

>>656
まぁ、普通は意味が無いけど、場合によっては意味がある。

たとえばプロトコルに通信シーケンスがずれた場合の復旧処置が
含まれている場合。相手側は次のトークンを待っている可能性がある。

後はバッドノウハウだけど、単純に相手側とか、プロトコルスタックの
バグで、後続のデータを受信すると正常に動き始めるとかｗｗｗ

イー・アクセスが通信障害の原因を発表、人的操作ミスとソフト不具合が重なる　2012/09/06
http://itpro.nikkeibp.co.jp/article/NEWS/20120906/421101/?top_tl2

　イー・アクセスは2012年9月6日、5日午後6時51分から午後11時34分にかけて、
12都府県で携帯電話の音声通話とデータ通信が利用しづらい状況に陥った障害の
原因を公表した。保守作業時の人的操作ミスとソフトウエアの不具合が重なった。
影響数は最大約27万人としている。
　同社は「ネットワークオペレーションセンター」（関連記事）で携帯電話網を
遠隔監視しているが、5日の保守作業時に基地局の状態を調べるコマンドの
パラメータを間違えて設定してしまったという。パラメータを誤ったコマンドは
システム側ではじく仕組みとしていたが、ソフトウエアの不具合で有効に機能せず、
そのまま実行されて「基地局が異常な状態に陥ってしまった」（同社）。
同社は影響を受けた基地局の数を非公表としているが、12都府県のある程度
まとまった単位の基地局に対して同コマンドを実行してしまったとみられる。
　最終的に問題の基地局を遠隔から再起動させることで対処したが、原因の究明に
手間取り、復旧までに約5時間弱を要する結果となった。
　イー・アクセスは今後の再発防止策として、
（1）保守作業方法の事前チェック体制の強化、
（2）作業プロセス上のチェック工程の改善、
（3）ソフトウエアの不具合の改修の3点を挙げた。
（1）と（2）について既に対処済みで、（3）についても速やかに実施するという。

>>657
シーケンスずれてしまって毎回 slow timer 一回待つってやつか?

モルピグ作りたいんすけど普通はＵＤPとかゆうの使うんすか？？？？？

WinSock2でパケットキャプチャをしてたんですけど
どうも大量データを受信したときに取りこぼしが出てしまい
WinPcapを使ってみようと下記を参考にしてみたんですが
やはり取りこぼしが出てしまいます。
取りこぼしが出るのは仕方のないことなんでしょうか？
http://homepage3.nifty.com/teatea/parasite/CSmemo.htm#packet

>処理の間に溜ったメッセージをパージする
これやってんじゃねえの？

>>661
そう

キャプチャ用のバッファーがあってそれが溢れちゃうみたいですね。
それなら仕方ないか・・・

全部表示すんじゃなくて、IPとかの必要なもんだけ表示するとかやってみたら
基本的に狙い撃ちみたいなことしないと

表示デバイスってのは人が思う以上にとんでもなく遅いから
ログを記録してから検索するとかしないと簡単にあふれる。

自分のは表示はしてないんですけどね。
まあ取りこぼしは仕方ないみたいですね。

きちんとやるなら、ハードウェアでやるしかないんだろうな。
http://www.lineeye.co.jp/html/product_LE-580FX.html

これでも、半二重 90Mbps、全二重 120Mbps 程度が限界らしい。

linux上で、XDRというデータ形式を使用して通信しています。

クライアント側（linux 32bit又は64bit）でデータをENCODEし、サーバ側（linux 64bit）でDECODEしています。
ENCODEする際に、OSによりxdr_u_long又はxdr_int64_tを使用しているのですが、サーバ側でどのデータ型で
ENCODEした際のデータ型を知ることはできますでしょうか？

また、DECODEする際にxdr_u_long等の関数を呼び出すと内部のポインタが進んでしまうのですが、戻すことは可能でしょうか。

クライアント側のプログラムの入れ替えができない為、32bit,64bit共にxdr_int64_tを使用する方式に変更できない状況です。

>>669
ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltok/index.html
net経由でやり取りしてるからと、ここで質問してる時点で...

>>670
ありがとうございます。

教えて頂いたページは確認済みです。
以下のリンクの情報でx_privateにデータが格納されている事まで確認しました。
x_privateのサイズから型を予想しようとmalloc_usable_sizeでサイズをとったのですが、
longの時とint64でサイズ同じで判断できなかったため、知っている方がおりましたら、
アドバイスを頂きたいと思っています。

ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltoc/index.html

小さい方に合わせるんじゃないの

linuxの場合
longは
32bitOSで4バイト
64bitOSで8バイト

メモリ確保する時のポインタサイズは
32bitOSで4バイト
64bitOSで8バイト

言葉知ってるだけじゃ、そのうち潰れるよ

XDR ストリームインタフェースはバカなりの解釈だと
32bitアプリと64biアプリの型の隠蔽するのに関数ポインタを使って
場合分けしましょうってことで
受け渡しに使うもんじゃないって読めるな

質問の内容が高度すぎて、バカには何を質問してるのか、わからん

あーC言語とかのlongかー

>>672

ありがとうございます。

質問内容がわかりづらく申し訳ないです。

既存のシステムでXDRを使用してデータの受け渡しをしています。
サーバ、クライアント共に32ビットOSです。
ハードウェアの老朽化対応でサーバと一部クライアントのOSを64ビットにすることになりました。

上記のような状態で、交換前のクライアントは32ビットのため、クライアントは32ビットと64ビットが混在しています。
受け渡しデータが環境依存のデータで、32ビット時は4バイト、64ビット時は8バイトのデータをサーバに渡す必要があり、
サーバ側でDECODEする際にENCODEした時のデータ型を判断したいという内容です。

>>674
ただのデータ変換にnetがどうのとか意味不明なの
最初にデータ構造考えた人に質問したほうがいいよ

ストリームに何が入っているか判断するのは自己責任です。
タグでもなければ判断しようがない。

なんか聞き覚えるなと思ってググッたら
メガドラで出てたんだな

>>674
おそらく根本的な考え違いをしている(>>672も同じく)
すでに他の人(>>675,676)が指摘しているけど、
エンコードされたXDRデータには、そのデータ型を表現する情報は一切含まれていない

たとえばXMLであれば(XML Schema や Relax NG といった)スキーマ定義が無くても
タグがあるから受信側でXMLデータを(ある程度までは)解釈できる
JSONにしても、(リストやハッシュといった)構文からデータ構造を推測できる

しかし(繰り返しになるが)XDRにはこういった柔軟性は存在しない(=XMLやJSONの常識は通用しない)
>>674がやろうとしているのは、あるC言語の構造体のバイナリダンプを渡されて、
その構造体が定義されたヘッダファイル無しにダンプ解析を試みるに等しい

素直に、その既存システムが開発された時に作成されたXDR定義ファイル(*.xdr)を入手しなさい
もしもそのファイルが入手できないことを承知で案件を引き受けてしまったのなら、
その判断を下した馬鹿者の責任だから、傷が大きくならないうちにお客様にゴメンナサイを言うべき

streamじゃなければ、staticに型は決まってますよ。

>>679
その「型紙」を寄越せ、っつってんだろ

て言うか何らかの手段で型紙を識別できる仕組み作らないと無理だろ。

そもそも「クライアント側のプログラムの入れ替えができない」とか書いてる割には、
「64ビット時は8バイトのデータをサーバに渡す必要があり」と書いてる。

まあ、マジだったとしても本人よく理解してないだろうし、スルーでいいと思うよ。

>>680
streamなんですよ。

I stream

You stream

好きさ！

じじいがいる

ばばあの可能性は？

夏のおじいさん

ジジイ、ジジイか
それじゃあお前は何だ、このガキが
俺はお前さんがこの世に落っこってくる前からコード書いてんだ

とすると70〜80歳か。 すげぇな・・・

ひんと：>>689 には元ネタあり

>>690
とすると55〜65歳か。 すげぇな・・・

あーそんな昔じゃコード書くのもっと年くってからか。

送り手が送ってこない情報を受け手側で判断したいという
無理難題だから誰にも解決はできない。

この板にはエスパーが居るんだから、そのエスパーをプログラミングすればいいんだよ

解決しました。

int64でデータを取得し、上位4バイトの値の有無でOSの32ビット、64ビットを判定することにしました。

お騒がせしました。

補足です。

みなさんのアドバイスで、streamからの判断できないことがわかったため、
データ構造から判定することにしました。

4バイトを超えない値が格納されるデータが2連続している場所（OSにより、領域は4*2または8*2バイト使用）があるので、
そこからINT64で取得して上位4バイトの有無を調べます。
※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。

int64は32bitOSでも64bit
packしたところで変わらんと思うんだが

32bit Linuxが送ってくる64bitポインタの上位32bitが
必ず0である保証がないと成立しないね。
同様に64bit Linuxが送ってくる64bitポインタの上位32bitが
必ず0以外である保証もないと成立しない。

いろいろ危うい前提条件に立った判定方法だと思う。
設計段階からやり直したほうがよさそう。

まあ本人納得してるんだからいいんじゃね。

問題が起こる前に転職すればいい。

>>699
クライアント側はいじれないって前提読めよ。

その前提があったからといって危ういことに変わりはない。
だとしたらなおさら「それはできません」以外の答えはないと思う。

それがあったので。

>>703
>だとしたらなおさら「それはできません」以外の答えはないと思う。

仕事したことない奴が言うことだな。

ないのは知恵。

保証できない前提条件に基づいたソフトウェアを検収するような
会社ならそれでいいんだろうけどねぇ。

> ※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。

どこがご不満で?
xdr streamのごくありきたりな使い方ですが?

保証できない？

> ※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。

が、保証されてりゃ十分だろ。

もちろん今後の仕様変更には注意が必要だから、お客さんにはよく言い含める必要はあるけど、
それはまた違う話だしね。

被った…

>>708
ありきたりじゃないと思うが…

普通、最初の方にバージョンとか、特性とかの情報を埋め込んでおくのが常套手段と思う。

普通にクライアント側のプログラムは無理して64ビットにする必要ないじゃん。
クライアント側プログラム変更できないのに、なんで64ビットに出来るんだよ。
変更できてるじゃん。

この時点で質問の前提がウソ。

と、意味不明の供述を続けており

>>699
32bit中上8bitとか1bitを別の目的で使っていたシステムみたいだね。
でもint64はポインタじゃないよ？

>>703
システム知らんけど、
64bit側でもint32に入りきる範囲の正の数値しか扱っていない前提なら、
int64でエンコードされていても上位32bitはALL0になるのは保証される

混乱させてしまい、申し訳ないです。追加補足します。

・現在、32ビットでサーバ、クライアントが稼働中。クライアント台数多
・ハードウェア老朽化で移行作業をすすめている。64ビットOSに変更
・32ビットOSから64ビットOSに変更する事は決定事項で口を出せる立場にはいない
・稼働中のクライアントプログラムの入れ替えはできない。
・新規に追加されるクライアントは64ビットのOSで追加する。
・最初に更改されるのはサーバ（64ビットになる）

上記の状態で、調査を実施し、一部の通信データでlongが使用されていた。
これは、32ビットと64ビットでサイズが異なってしまうため、32ビット分しか使用されていないか調査した。
※問題なければ、intにキャストして解決しようとしていた。
しかし、全体の中の一部だけOS依存のデータがあり、8バイトになってしまうものがあった。
上記理由のため、64ビット版ではクライアント側、OS側共にlong部分をINT64に変更する必要がでた。

まずはサーバ移行のため、32ビット版だけに対応していれば、すぐには問題がでないが、段階的に64ビットの
クライアントが導入された際に問題がでるため、対応方法を検討していました。
XDRは使用した事がなく、調査したが対応策を発見できなかった為、使用経験がある方からのアドバイスを頂きたく、相談しました。

今回の対応方法はデータ仕様依存があるので、仕様変更された際には保証ができませんが、>>709さんが書いてあるとおり、
現時点では問題ないと認識しています。

まんどくせーけど

ありがちな崩壊しているシステムなのだろう

崩壊してるのはお前の頭。

崩壊しているというか、拡張性を考えていない仕様だったということだろ。

最初の仕様考えた奴が、あまりこういう経験なかったんだろ。

そういうことで崩壊しているといってるのだが

717はデスマでいってよし

ていうか、そもそもプログラムを64bitで動かす必要があるのかどうかが激しく疑問なのだけど。
読んだ限り、「64bitOSにしたから64bit版に変えたい」という以外に見当たらないような。

デスマ助けるのがこういうハックでしょ。
頭固くて馬鹿そうだねえ。

ただで助ける馬鹿がどこにいる

デスマになる理由分かる？

投資労さん

64ビットOS移行は動かせなくても、そのうえで32ビットのクライアントプログラム
動かすのは制約条件に入ってないから全然問題ないじゃん。
必死になってクライアントプログラムの64ビット化進めるメリットなんてまるでない。(営業上の理由?)
アホかと1000回言いたい。

何を必死になってるのか良くわからんけど、メリットなんてよその
人間にわかるわけがない。

営業上の理由かもしれないし、そもそも 64bit 版では 32bit の
プログラムが動かないＯＳかもしれない。

そうだよ

よそのデスマ、めしうまー

すぐに解決してしまって、何もデスマになってないw

なんか燃料投下しているようで申し訳ない。

新しいクライアントの64ビット化に対応するのは必要な部分のみです。

既存で動いているので、基本は新OSで再コンパイルだけで終わらせたいと思っています。

しかし、>>715に記載しているのですが、OS依存のデータが一部あり、OSが変わった事で4バイトだった物が8バイトになってしまったものがあります。
対応しないで4バイトで切り捨てした場合、動作が保証できなくなる不都合があり、必要最低限の対応を行うという物です。

「32bitコードのままではいけない」という理由の説明になってないよ。
具体的に「何が8バイトになったのか」を示さないと。

散々いわれてるけど「64bitOSでも32bitプログラムはそのまま動く(大半は)」ので
いわゆる64bit処理系で起こる「ポインタが64bit」「longが64bit」というのは
「64bitプログラムにしたから起こること」であって
「32bitプログラムのままではいけない理由」にはならない。

もちろん、「命令によりとにかく64bitプログラムにしなければいけない」というのも
十分な理由ではあるけれど、
それなら「OS依存のデータ云々」は関係ないよね。

いいじゃねーか

馬鹿ユーザに馬鹿害虫

馬鹿害虫に想像力がないだけだろ。

例えばそのプログラムが物理メモリーの最大値を返すとか言うのが想像できないんだろ。

※ 一部の 32bit OS では、4GB 以上の物理メモリーをサポートするけど、一例だからね。

>>715,727(>>669)
(ネットワーク上を流れる)外部データ表現と(OS内部の)内部データ表現との違いを間違って理解している
XDR(eXternal Data presentation)は通信規格だから、
(一般的な)整数型は(OSの違いとは無関係に)32bit固定と明確に仕様が定義されている
(これはC言語上でのデータ型 short/int/long のどれであっても同じで、通信データとしては全て32bit)
そして、long型のOS内部表現では大きさが32bit/64bitとかエンディアンといった差異が
存在するから、それらを吸収させる為に xdr_xxx という変換関数がライブラリとして提供されている
だから「32ビットと64ビットで(通信データの)サイズが異なってしまう」なんてことはありえなくて、
普通は xdr_long を呼ぶコードには何ら修正を加えること無くリコンパイルするだけで終わる

以下は「Solaris 64 ビット開発ガイド」p.64 からの引用(題名でググればPDFで読める)
　　XDR ルーチンの xdr_long(3NSL) は問題と思われるかもしれません。しかし、これは
　　既存のプロトコルとの互換性を持たせるために従来どおり 32 ビットとして取り扱われます。
　　64 ビットバージョンのルーチンが 32 ビットに格納できない long 値を
　　コード化するように要求された場合、そのコード化処理は失敗します。

何を力説してるのか知らんけど、そういう問題じゃないから。

今までの32ビットプログラム/32ビットOSで32ビットで見えていたOSのリソースが
32ビットプログラム/64ビットOSになると64ビット必要になるというのは何だろう。
物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。

>>734
> 物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。

そんなに悔しかったのかよ (w

>>734
まぁ、手っ取り早く移植したいなら、
typedef int longとでもすれば済む話だしな。

>>736
全ライブラリにそう書いて回るの？ 大変だね

includeすればいいだろう

組み込み型をtypedefてw

intをlongにしてgccをrebulidするんだよ

64ビット用のサーバーは32ビット用と分ければいいのではないか
64bitのクライアントは64bitのサーバーに接続する。
なんというすばらしい発想の転換

IPv6 クライアントも IPv6 サーバーにしか繋がらないようにすれば良かったのに

みんなひまだなー

元のデータ構造が
int,long
ごちゃまぜなんじゃね

もう>>741が最強すぎて話にならない

何のためにRPCを使ってるか

ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltoc/index.html
これ使って、ハマらないようにしましょうって、言ってるのもわからないんだ

>>747
>>733

?

高脳の言ってることはよーわからんなあ

一番簡単な方法
逝ってるな64bitOSなら
32アプリが動くような環境作ればいいだけ
移植もへったくれもない

RPCでlongとか使ってるプログラム作った外注か社員は、
速攻追放した方がいいよ。この先もどんどんコストかかるような
バカやらかすよ。

>>751
まだ馬鹿晒すのかよ…

別にバカの自覚あるから、何言われても平気だけど
まともな反論してみな

ネットワーク越しに OS依存のデータを送る/受ける欲求ってありえるの？

盛り上がってるな。
よくわからんが、

struct T { size_t file_size; time_t creation_time };

みたいなレコードをクライアントからサーバに送る処理があって、
32bit OSのクライアントはint32型の値を並べて送ってくるけど、
64bit OSはint64型の値を並べ絵送ってくる。
これをストリームとして受信しているサーバ側で区別したいということかな？

むしろfile_sizeが2^32を超えたとかcreation_timeが2^32を超えたとか
そういう話らしい。
もちろんこの場合は64bitOSとは全然関係ないけれど。

>>752
キャストを間違える、APIの戻り値をハードコードする、
そんなバカな派遣のじじいがいるんだけど、どうやって
追い出したらいいかな。NULLは0だと力説する気狂い。

ハマってる当事者は高度なことやらないといけないと思ってるみたいだね

>>755
SNMP真っ向から否定かよw

>>760
OSには依存してないだろ！

SNMPって、言ってみただけですから

普通にblobやり取りされてるけど…

>>763
それがどうした

"OCTET STRING"くらい知っておこう。

>>756
おそらく質問主(>>669)は、そのように考えていたのだと思う

しかし、今回の64bit版サーバ＆クライアント開発のケースでは、
・64bit化に伴なう機能の追加や変更は一切無く(>>715,727)、しかも
・整数値は必ず32bitに格納できる(>>679)
わけだから、(>>732で書いたように)クライアントのOSが32bit/64bitのどちらであっても
(XDRでエンコードされて)ネットワーク上を流れる通信データは32bit表現のままで何も問題は無かった

結論としては、32bit版のコード内にある xdr_u_long の部分を「わざわざ」 xdr_int64_t へと
修正したこと(>>669)そのものが誤りであり、その「余計な行為」がバグを作り込んでしまったと言える
言い換えると、既存の32bit版システムで使われていた通信プロトコル仕様における整数表現形式を
32bitから64bitへと「意図せず」に改変(改悪？)したことになる

>>766
余計な行為じゃねーだろ、意図もしてるし。

>>715 全体の中の一部だけOS依存のデータがあり、8バイトになってしまうものがあった。

ただ修正の方法が間違っているとは思う。

>>754
反論なんているか？
普通の頭持ってたら、>>751 が意味ないことがわかると思うんだが…(w

言葉（単語）だけでその先を知らないんじゃねえの？

バカなのは767。
751は正しい。

まず、>>766内のアンカに誤りがあったので訂正する
　X: ・整数値は必ず32bitに格納できる(>>679)
　O: ・整数値は必ず32bitに格納できる(>>697)

>>767
>余計な行為じゃねーだろ、意図もしてるし。

他の何人かも指摘しているけど、ネットワーク上を流れる通信データとして
OS依存な表現が必要であるという意図(あるいは事情)が(自分には)想像できない
ありえるとすれば、共用メモリ/ファイル共有/プロセス移送といった分散OS的なメカニズムを
実装するケースがあるけど、はたして>>669担当のシステムがそれに該当するのか疑わしい....

で、もしも通信データとして64bit整数(= XDR規格における hyper整数)が「本当に」必要であったのなら、
正式な手順に従って通信プロトコル仕様を改訂し、その工数を見積もりで計上すべきだったと考える
ここで、プロトコル仕様にプロトコルバージョンの概念が含まれていればアップすることで対応できるし、
もし無ければ新たにポート番号を割り当て、プロトコルバージョンを含む新プロトコルとして扱うことになる

>>769
>>754

>>770
> 他の何人かも指摘しているけど、ネットワーク上を流れる通信データとして
> OS依存な表現が必要であるという意図(あるいは事情)が(自分には)想像できない

表現って何を言ってるのか知らんけど、上にも上げた物理メモリーの容量とかを
サーバーに送るとかは別に珍しくないと思うが。

> プロトコル仕様にプロトコルバージョンの概念が含まれていればアップすることで対応できるし、
> もし無ければ新たにポート番号を割り当て、プロトコルバージョンを含む新プロトコルとして扱うことになる

バージョンがあったらこんなに盛り上がってないし、F/W とかの絡みでポート番号をほいほい
変えられない環境って結構ある。

とにかく、「疑わしい」とか上から目線で語りたいなら、もう少し世間を知った方がいいと思うぞ。
まあ、分散ＯＳって言いたいだけのおこちゃまなんだろうけど。(w

クライアント側が先に作られてしまったけど、立場が弱くてサーバー側からは
直せとは言えないとか、そういうくだらない理由なんだろうな。技術的な話じゃなくて。

32bit用にビルドして動かせば、longだって32bitのままなのに。
え？サーバの64bitの値を取得したいって？
そんなの対応してないから無理。64bitでビルドすればとれるってのは
幻想だよ幻想。

クライアントからデータを送る事例なんじゃないのか？

>>772
て言うか、32bit 版のクライアント配りまくってていまさら入れ替えなんて出来ない状況とかなんだろ。

まあ、それなりにありえる話だと思うぞ。

だからこそ、普通はプロトコルバージョンとかを頭に入れておくとかするんだが、まあ仕様決めた奴が
馬鹿だったんだろうな。

>>771
無能全開で楽しそうだね

逃亡したか。やはりlongとintを区別せずに書いたアプリで32ビットと64ビットが
混乱してるだけなんだろうな。
64ビットOSでも32ビットでコンパイルしたものを動かせば完了だろう。

>>771がファビョってるが、物理メモリ以外の64ビット必要なデータが出てこないな。
ファイルサイズやtime_tは32ビットOSでも既に64ビット化されてるから問題ないし。
物理メモリも32ビットOSでも4G超えてる場合もあったので、今更必死で対応する必要ないな。

>>777
仕事しろ、無能が

>>777
＞time_tは32ビットOSでも既に64ビット化されてるから問題ないし。
嘘をつくな！
Linuxの32bit版カーネルではtime_tは32ビットのままだ！

ごめんカーネルじゃないやlibcだった

#define __TIME_T_TYPE __SYSCALL_SLONG_TYPE

>>781
お前馬鹿だろ。9/14のメール読んでみろ。

> 9/14のメール
?

バカじゃないと主張したいらしいが
バカ未満だと認識されてるのもわかってないとか

確かにtime_tはlongのままだね
今更long longにはできんよなぁ

はあ？

あはー

>>776
>>754

>>777
> 逃亡したか。

平日の昼間までにちゃんできるお前に同情してやるよ。

> やはりlongとintを区別せずに書いたアプリで32ビットと64ビットが混乱してるだけなんだろうな。

そんな馬鹿は今時お前ぐらいしかいないよ。
万が一そうだったとしても64bit 版はいくらでも手を入れられるんだから、問題ないし。
そもそも、そういう問題じゃないと >>715 で明記してるし。

> 物理メモリ以外の64ビット必要なデータが出てこないな。

ひょっとして「物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。」と言ってた
馬鹿？ (w

715で答え書いてるのに今だに悩んでるところがお笑い

webで書かれた手順もへったくれもない方法でやってますって、自白してるんだけどね

64bitのlinux環境だと起動やり直すとメモリ確保した時に同じにならないようになってたような

>>791
32bitでも同じにならないよ

でもあと30年ちょっとで2038年になるんだよな
32ビット版Linuxってそれまでに駆逐されるんだろうか

なくなりはしないと思うけどメモリ拡張に制限はつくし
CPUは例外なく64bit化が完了しているし、プログラム
のバイナリ互換性が問題にならないシステムは順次
64bitに置き換わっていくんじゃないかね。

もう保険やら住宅ローンやらで2038年越えデータもちらほらあるしねｗ

>でもあと30年ちょっとで2038年になるんだよな

足し算も出来ない知障か
それともこぴぺか

まともにメンテされないOSとその一味でも使ってるのかいな？
お祭り騒ぎにしてひと儲けとかもう無理だから

あと20年は32ビットos残るだろうしなあ

2038年問題は32bitOSがどうのこうのという問題ではない。

20年後は128bit化してるだろ

>NTPやMicrosoft Windowsなど、
>1900年1月1日からの積算秒数で時間を表現するシステムもあり、
>符号なし32ビットの値が2036年2月6日にオーバーフローすることによって
>問題が発生する（→2036年問題）。
64bit長にすれば、なんでもないことでしょ
対応できないようなアプリ作りこむ人達がいるってだけ

NTPはその問題先読みした設計になってたような

20年後なら256bitになってないとおかしい

> 2004年1月10日に「16進数で最初の桁に1が立ち、“負の数”と認識される」（KDDI広報）トラブルが発生した。

16進数というのはネタなのかガチなのか

>>799
linux以外ではね

>>801
最近直した

すべてがFになった

>>804
10進だったらウチでもあったな。
日時順で処理するフラグとしてファイル名にUNIX timeを付けてたら
桁が上がってソート順が変わってしまったｗ
あれはいつのことだっけ？

3流の釣り師が...

>>808
そんなこともあったねぇ・・・

このころ
http://mimizun.com/log/2ch/accuse/1000000000/

まあ、9が10になったり99が100になったりしたときに
桁数の問題ではなくソート順の問題が出てくるというのも、よくあることだね。

>>807
冷密のきっちりしたロジックのほうがすき！

馬鹿がプログラムしてるからだろう、だったろう

>>812
冷凍庫のぎっしりしたジップロックのほうがすき!

>>790
かわいそうな人…、まあ頑張れよ。(w

別に当事者じゃないから関係ないんだけどね

>>801
>>806
うるう秒の処理にバグがあってシステムごと落ちてたあれか

>>793

>>805
つまりどういうことです？

パソコンを窓から投げ捨てろ
ってこと

ちょっとまって、準備するから

NICの動作モードを取得する方法 (API?) を教えて下さい
知りたいのは半二重、全二重のどちらで動作しているか、です

アダプタの設定ではなく、実際に動作(リンク)しているモードです
Win32_NetworkAdapter classの中には該当するメソッドやプロパティは見当たらないようです

同軸ケーブルな環境でやってるの？

NICのことはNICに聞け

>>823
同軸だったら調べるまでもないだろ

>>822
wmi

半二重、全二重
とかわからなくても、動かす分には関係無いような

>>826
wmiのドキュメントをざっと見てみたのですが、取得の方法がよくわかりませんでした
メソッドの一覧を見た感じ、データリンク層とはあんまり関係ないような気もします

>>827
組み込み制御用のマシンなんですが、全二重になっていないと遅延とデータ量の関係で取りこぼしが発生する可能性があるため
デバッグ用のWindowsマシンを接続した時にNICにモードを自動判別させて、その結果を知りたいのです
スイッチングハブをはさんでLEDで確認するという方法も提案したのですが、できればソフトウェアでやりたいということで

>>828
その馬鹿プログラムを直せよ

だったらオートネゴやめて全二重固定にした方がいいと思うが。

>>828
そのマシンの鳥説よめよ

というか組み込みプログラムに向いてないからやめたら

帯域絞るときは送信側から送るデータを絞ればいいの？
1Mbpsにしたかったら毎秒1MBしか送信しないようにすればいいの？

受信側を1Mbpsにしても絞れる？
受信側を1Mbpsにしても送信側の帯域はMAXで一気に送信してしまう？

ネット以前に通信の基本的なところからやり直したら

帯域幅ってのはようは平均値だから、大量のパケットの流れとしてみる場合は意味があるが、
個々のパケットのタイミングで考える場合は期間のとり方でいくらでも変わる。
極端には、パケットを送出している範囲に限れば帯域をMAXで使っていることになる。

>>833
YES
>>834
YES

>>822
NDIS対応のEthernetインターフェースならなんとか取得できるだろうけど、
SNMPサーバをたちあげてSNMP経由で取得するのがいいと思う。

LANケーブルの構造も知らんでネット？の事やってるんか？

UTPとか同軸と言わずにLANケーブルと言っている時点で…それ以前にRJ45とかコネクタの問題か。

LANケーブルがmetalとは限らないし

アプリで半二重とかわかったところでなにか変わったことが出来るのかね

わーい、いっぱいつっこまれてる

SNMPてクライアント側でデーモン動いてなくても、通信モードまで取得できたっけ？

なんで、スイッチングハブがあるのか、よーく、考えてみようね

>>844
出直してこい。

ちなみにLinuxだとこんな感じでいいのかな。
$ cat /sys/class/net/eth0/duplex
full

バカな客や営業を納得させるのは面倒だから、データ落ちが起こらないように
きっちりバッファリングする提案(開発費大)と、全二重チェックして半二重だったら
止める(開発費小)を提案して選ばせるのはありかと。

はあああああ？

>>849
わかってないバカがまだいるのか。現実直視しろよ。
開発に求められているのは機能や品質じゃなくて、コストなんだよ。
自分が担当しているうちに問題起きなきゃOK。
最善の解を追及するなんて不可能。つまらない業界に成り果ててる。

無能言い訳は相変わらず、金（通貨）先の発想かよ
問題（課題）に対しての読解力でも磨いたら

半二重を逃げに理由にしたいだけか？
多分、半二重の環境探してみても、見つからんだろうね

金勘定のできない無能は去った方がいいぞ。

カネ勘定だけしか出来ない無能がいっぱいいるのか？

論理的に説明できなくて煽ることしか出来ない無能をスルーするのが正解

質問者は接続中のメディア種別の取得方法を聞いてるだけ。
前提が全く不明なのに、それは正しくないとか金勘定もできないカタワの
公開オナニーほど見苦しいものは無い。

バカにもなりきれん奴が作れるもんってなあに？

windowsなら、レジストリ漁れば、見つかるんじゃね
こんな簡単なやり方も思いつかんの？

金があれば正しく解決できるし
なければ応急処置しかできない

というだけのはなしだろ。むずかしいことじゃない。

おまえの発言いちいちズレてるよな

>>860
どうズレてるのか説明しろ

>>861
>>856を1000回読め
さらにズレてる上に間違ってる
金があれば正しく解決できるとは限らない
応急処置しかできないとも限らない

なんでそんな必死なん？

無駄なことヤメレに対して金出さないバカクライアントが居るから
という状況の説明するのは普通のことだろ...

質問者はプログラムが動かない(データドロップする)言い訳探してるだけでしょ。
あんまり付き合う気にならないけど、引導渡してやるから成仏しろ。

http://itknowledgeexchange.techtarget.com/powershell/network-adapter-speed-and-duplex/

>>864
それって実際の動作モードじゃないじゃん
こんな短いソースなんだから中身読んでから貼れよ

ここで仕事の内容を晒してることもわかってない

>>866
こんな断片情報で仕事の内容とか腹痛い

じゃあ、無能自慢？

ちょうどいい逃避のネタが

かれこれ2時間ぐらい検索してるけど
海外の掲示板なんかを見ても定期的に出てくる話題っぽい
MSの掲示板でも中の人ができないって言ってるけど本当に無理なのか

アプリで半二重っぽいことすればいいだけ
他のアプリがnet使わない条件でね

>>870
ネットワークカードを直接叩くの？

ルーター通るとどうなるか、調べてみたら

>>865
言い訳になるが有線な環境ないんだよ。↓に状態が出るもんだと思い込んでた。
> イーサネット アダプター ローカル エリア接続:
> メディアの状態. . . . . . . . . . : メディアは接続されていません

こんなのが引っかかったが、ドライバ別に取るしかない?
http://social.msdn.microsoft.com/Forums/en-US/wsk/thread/4baaaabb-cc77-4bd0-91da-00dff3792742/

全二重か半二重かを、特定の機器に依存する方法以外で検出するのは無理じゃないの？
だって、2台をつなぐ時でさえ、間にいくつのハブが挟まってるかわからないと思うから。

全二重/半二重の区別は、NICやスイッチ/ハブとの間の個々の区間で
それぞれ個別に設定されているんじゃないかな。
そして、その個々の区間の終端はMACを持ってないものも多いはず。

>>871
フォトカプラとDIOボードを使えば何とかなると思う。

チップからステータス読めば？
intelと蟹の2種類あれば十分でしょ

>>828で組み込み制御と書いているから、peer接続してるかも。運用の人がCAT1のUTPで繋いだ時に検出するとか。UTPの断線で4芯2対として動いた場合とか。
そもそもプロトコルもIPとかじゃないだろうし。

↓NDISのmedia duplex speedって聞いて分からない人はどうしようもないと思ったほうがいい。
上に書いたようにSNMPに頼ってください。

msdnにあった

ttp://msdn.microsoft.com/en-us/library/windows/hardware/hh205390(v=vs.85).aspx

構造体の中に
　NDIS_MEDIA_CONNECT_STATE MediaConnectState;
　NDIS_MEDIA_DUPLEX_STATE MediaDuplexState;
　ULONG64 XmitLinkSpeed;
　ULONG64 RcvLinkSpeed;

ってあるから、これで読み出せるんでね？

ところがチップによってサポートしてたりしてなかったり。
その辺は自力で調べる必要がある。
英語読めない人は不可能と思った方がいい。
もともと3ComとMicrosoftの決めた古い規格なんで。

SO_KEEPALIVEについて教えてください。
サーバ１つでクライアントが複数ある場合
接続してきたクライアントが有効か否かをチェックする為にSO_KEEPALIVEを使用しようと思っています。
SO_KEEPALIVEはサーバで生成したソケットに対して設定すればよいのでしょうか？
それともacceptしてきたクライアントのソケットに設定するのでしょうか？

>>881
アクセプトしたやつにつける

ごめん、両方

>>883
ありがとうございます。
ちなみにクライアント側のconnectするソケットにも設定する必要がありますか？

>>884
KEEPALIVEは、 投げるか投げないか の設定なのよ。

つまり、KEEPALIVE設定した方は切断を検知するけど
KEEPALIVEを設定して無い側は切断を検知しないんよ。

>>885
承知しました。知りたいのはサーバ側なのでクライアント側には設定しないようにします。

KEEPALIVEを設定してみたのですがConnection timed outというエラーが出ます。
開始までを120秒、リトライ間隔を30秒、リトライ回数5回としてやっています。
ネットは常に接続している状態だし、ルータの自動切断する時間よりも短い感覚です。
なぜエラーになるのでしょうか？

>>886
KEEPALIVEを設定しないとちゃんと接続できるのか？

デフォールトの接続タイムアウトはOSによっても異なる

KEEPALIVE設定したからってConnection timed outはないだろう。
なんか間違ってるよ。

>>881
> 接続してきたクライアントが有効か否かをチェックする為にSO_KEEPALIVEを使用しようと思っています。

そのような目的にSO_KEEPALIVEを使うことはできません。
放置されても接続が破棄されにくくすることが出来るだけです。

>>885
何か別のものと間違えてませんか?

必要もないのに接続したままにするなよな

私ら界隈では、むしろいちいち切断する方が異端らしい‥‥医療機器通信関連ですけど

KEEPALIVEを投げる側しか切断を検知できないってのは間違ってないと思うが？

>>893
違います

>>892
そりゃそういう分野だし仕方ない

>>894
どういうふうに違うの？

手持ちのUNIXネットワークプログラミング第2版vol.1 p179には
『本オプションの目的は、相手ホストのクラッシュを検出することにある』
と書いてあるし、実験でも本番でもそういう挙動しかみたことないけど

どこか間違ってたら訂正するので教えてください。

>>894
いや、原理的にさ、パケットを投げてない側は切断を検知しようがないじゃん。

>>897
いいえ。

>>890
>>894
>>898
悔しさは伝わった。

議論が混乱しているみたいなので、整理してみる....

SO_KEEPALIVEの目的は二つある
・APの無通信状態が継続していてもTCPコネクションの自動切断を抑止する
　　==>「放置されても接続が破棄されにくくすることが出来る(>>890)」
・下位層異常を検知してTCPコネクションを自動的に切断する
　　==> 「SO_KEEPALIVEを設定した(投げる)側だけが切断を検知できる(>>885,893)」

つまり、>>890と>>885,893の指摘のどちらも「TCPコネクション接続後の自動切断処理」について
話しているから、両者の指摘はともに間違いではない
ただし、今の時代はWAN(広域ネットワーク)でも常時接続サービスが一般化しているから、
前者(>>890の自動切断の抑止)を目的にSO_KEEPALIVEを設定するケースは極めて限られると思う

そして、「TCPコネクション接続時のエラー検知処理」にSO_KEEPALIVEを利用しようという
質問者(>>881,886)の考え方が間違っている(=SO_KEEPALIVEの目的を誤解している)、と言える

>>896
APレベルとホストレベルは区別しましょう、目的は知らんが

>>901
何を言っているの？

>>900
常時接続だからセッションは切断されないって？
そんな認識でよく生き延びてこられたな

APレベルの話なんて誰もしてないけど？

tcpは無通信状態になっても切断しないがデフォなの

>>900
常時接続といっても、みんなNATになって逆に接続の維持を気にしなきゃ
ならん場面が増えたと思う。

>>905
無通信だからって自分でFINを投げることは無い
というところまではその認識で正しいよ

>>905
でもって無通信状態だと、相手が切断している事に気がつかないまま
ハーフオープンと言う状態に陥る場合がある。
これを防ぐためにKeepAliveを使う訳。

単なる無通信なのか相手がFINを投げずに切断の片開きなのかを区別したい　と。

>>908
まあ普通に切断してたら気づくけどな。
問題は無作法だったり、相手のホストがダウンしたり、
途中のファイアーウォールが接続を切ったりした場合。

>>909
いや、区別はつくけど、それは重要じゃないかな
とにかく相手と意思が疎通出来なさそうなら切る

>>902
馬鹿は相手にしない

>>911
SO_KEEPALIVEを使うのは、逆にアプリ側でそういったことを意識しないで
楽できるってことだと思うが。

>>913
そのためのKEEPALIVEですね

>>913
馬鹿乙

すべてのアプリに設定するのか

>>915
はぁ？>>913のように楽したいアプリだけ設定すりゃいいだろ？

>>916
わりい馬鹿だと思ってすべった

>>887
LAN環境なら接続を維持しています。

インターネットだとルータを通り、ルータには無通信状態のタイムアウトが
あるのでそれで切断されているようでした。
なのでKEEPALIVEを設定しています。

>>918
で目的は何？

>>919
・無通信状態によるルータの切断を防ぐ
・接続断を早期に検知する
だろ

これをアプリ層でやるのも面倒だからKEEPALIVEでやるのは
有田と思うよ

>>920
KeepAliveのデフォルト監視周期って2時間だろ。

>・無通信状態によるルータの切断を防ぐ
>・接続断を早期に検知する

上のような目的で、使い物になるの？

>>920
おまえは881か？

>>922
デフォルトのママ使って無いじゃん
>>886見る限り変更してる

>>922
> KeepAliveのデフォルト監視周期って2時間だろ。

そんな長いか？
15年ぐらい前にネットワーク対応の機器の開発やってた時は数分だったと思ったが。

そもそもディフォルトってなんかで決まってるのか？
決まってるなら、ソースよろ。

ディフォルトにすげー違和感

で、このスレに来てるのに>>1のFAQを全然読んでない、と。

２時間というのは決まっているわけではないけれど、ちゃんと根拠があり
少なくともFAQが書かれた当時には、ほぼ全ての実装がそうなっていた、と書いてある。
(SVR4.2も「変更可能である」というだけで「２時間ではない」とはなってない)
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-4.html#ss4.7

>>925
Linux使ってるなら、
/proc/sys/net/ipv4/tcp_keepalive_time
を見るといいよ

そういえばこれipv4なのな。ipv6ではどうなんの？

>>925
RFC1122
4.2.3.6 TCP Keep-Alives
This interval MUST be configurable and MUST default to no less than two hours.

何も考えないやつがnop送りまくらないように2時間以上にしとけってことか?
使うときは短くして使っていいんだよな。

自由に出来るならどうぞ。
システム全体でしか変更できないOSがほとんどだけどね。

ブロードキャスト指示型ワームってアイディアは良いよね
昔からあるんだろうけど何で警察はノーマークだったんだろ

質問です。
socketプログラムでselectを使用して送信可能か判断をしています。
FD_ISSETを判定して送信となった時sendで送信しますが、このsendはfor文で複数回呼んでもいいのでしょうか？
socketはブロッキングモードです。

>>933
送信不可になった時点でブロックされるから大丈夫

「私ならブロッキングモードは使わない、絶対に。」

絶対ニダ

そうだね

>>934
ということはブロックされたくないなら複数回呼んじゃ駄目ってことですね。

ノンブロッキングモードならsendする時selectを使う必要ないんでしょうか？

ノンブロッキングモードなら、sendしてもブロックされず、今は送信できませんエラーが返されるので、送信できるようになってから改めてsendを呼ぶ

>>938
承知しました。selectじゃなくsendの返り値で判断するんですね。ありがとうございます。

sendの返り値でも判断できるしselectでも判断できる
送信できるまで何度も繰り返しsendを呼びまくるのは効率悪いから普通はselect(とかpollとか)で待つけど、まぁ好きにすれば

selectで送信可能になるまで待ち、
sendで送信できる分だけ送信し、
送信し切れなければまたselectで待つ

国家も同じだ

キューが空ならsendで送信し、
　送信できなければキューに入れselectで送信可能になるまで待ち、
　selectで送信可能になったら、キューからsendで送信できる分だけ送信し、
　送信し切れなければまたselectで待つ

キューが空でなければキューに入れ、selectで送信可能になるまで待ち、
　selectで送信可能になったら、キューからsendで送信できる分だけ送信し、
　送信し切れなければまたselectで待つ

>>940
>>941
>>942
承知しました。
ブロッキングモードだと送信できませんエラーが返らずブロックするから駄目
って事ですよね。
ノンブロッキングにして教わったようにやってみます。ありがとうございました。

ばか

じじ

ずず

TCPのサーバプログラムでlistenした後、ノンブロッキング設定しました。
acceptで得られる接続してきたクライアントのソケットにもノンブロキッングモードを設定してやる必要がありますか？

>>947
listenソケットはどうでもいい
acceptしたソケットをこそノンブロックにしろ

>>948
承知しました。ではacceptで得られるソケットに設定します。
ありがとうございます。

もう一つ質問なのですがノンブロックの場合でデータが無い場合、EAGAINが返ってくるとありますが
それでデータの有無をチェックできるならselect要らないのではと思ったのですが必要でしょうか？

データが来るまで何千回だろうと何万回だろうとCPUぶん回して繰り返しrecvを呼び続けるというつもりなら要らない

ビジー・ウエイト/busy waitでググると良い。

>>949
そのためのselectです

selectの返り値でテータがあるか先に判断できるから複数あるソケットを
毎回ループしてチェックする必要がないという事ですね。ありがとうございました

いや、複数のイベントを「待つ」ためのものだが…

サーバプログラムでacceptしてきたソケットをノンブロッキングにしています。
ネットの回線を切断して、サーバからクライアントにデータをsendしても
recvにエラーが返ってこなくなったのですが、どうやって切断の検出をすればいいのでしょうか？

>>954
誤解だぜ・・・ n個のイベントを待つんだよ。

もちろん、0個のときだってある。

>>955
環境に依存しないのはタイムアウトぐらいしかないんじゃね？

>>950
わざわざカッコつけてるんだから、複数に力点がないことぐらい理解できるようになろうよ…

>>955
TCP keepalive あたりでググれば幸せになれるかも

初歩的な質問なんだけど、LAN内端末間通信ってIPアドレスとポートさえ分かれば特に何もしなくてもUDP通信できる？
struct sockaddr_in sock;
sock.sin_family = AF_INET;
sock.sin_addr.s_addr = inet_addr("127.0.0.1");
sock.sin_port = htons(12345);

C言語LINUXだけど、ここのIPアドレス部分にプライベートアドレス(111.111.111.111とか)書いても送れる？

何かしらしなければならない。
開けたり閉じたり書いたり読んだり。
特に何もしなくても通信できるとしたら、神からの啓示だ。

>プライベートアドレス(111.111.111.111とか)

えぇっ!?

>>959
まずは、やってみなよ。

どこの銀河系のIPアドレス空間だ？

こんなスレに来るんなら、nslookup の使い方ぐらい覚えろよ

C:\>nslookup
Default Server: local.gateway
Address: 192.168.1.1

> set type=PTR
> 111.111.111.111
Server: local.gateway
Address: 192.168.1.1

Non-authoritative answer:
111.111.111.111.in-addr.arpa name = KD111111111111.ppp-bb.dion.ne.jp

digすすめろよ

このHPの画像をC#等で取得したい。


isikawahuryouさん

このHPの画像をC#等で取得したい。

http://www.jartic.or.jp/ext_map.html?code=2001

このページになります。
ソース上でGIFファイルのファイル名が特定されていません。
いかがでしょうか。

>>966
取得できないようにがんばっているので
取得しないであげてください。
取得できる方法が確立されたら、
ほかの方法でさらに取得できないようにするだけです。

＞＞９６７
えっ、そうなんですか？
僕は、このサイトのGIFフィアルを定期的に取得して、
何曜日の何時頃、どこが混むのか知りたいのです。

Web製作板に行くとよい。

Firefox だと firebug
IE9 だと F12
で判る

city_highway/rmp200101/rmp200101.gif?dummy=は適当に変えるのが良さそう

うはー、やっぱりこの時間になると混んできますね・・・

ティクピッピ　ならできるぜ

>>958
キープアライブ実装で出来ました。ありがとうございます。
確認なのですが、ノンブロッキングでsendしてもエラーが返って来ないのは仕様ですか？
今まではキープアライブの変わりに一定間隔でダミーパケットを送信していたもので…

>>966-973
引数つけてるのは取得できないようにしてるんじゃなくキャッシュ回避だろ
定期的に保存したいなら時間情報使って保存ファイル名指定しろ

#数字には意味は何もない
url: "_json/map_" +_jsmode +".json?dummy=" + Math.random(),

マップの url は
/map/city_highway/rmp200101/rmp200101.gif?dummy=毎回異なる値
そのマップの時間は
/_json/map_city_highway_2001.json?dummy=毎回異なる値
で返ってくる JSON の viewdata[2001]['updtime']

>>974
ノンブロックの時、回線切断状態の時にsendしても
recvにエラーが返ってこないのは仕様ですか？の間違いです。

接続が切れたかどうかはわからないのが分散環境の基本。

>>977
普通に返ってくるだろ
まだ送信リトライしてる最中だろうから待てよ

必ず返ってくることを期待してプログラム書いてたり
タイムアウトの見切りが異常に遅い糞プログラム書いてると
Windows Vista / 7 の exoplorer のようになります

承知しました。ありがとうございます。
sendでさらに質問なのですが
複数あるクライアントの１つのソケットでsendがもう送れませんってエラーを返したら
他のクライアントにも送れないのでしょうか？

あ

い

〜

>>975-976
すみません、さっぱりわかりません。
もう少し噛み砕いて教えていただけないでしょうか。

落ちるで

ほ

>>985 「さっぱり」わからんなら少しはわかるまで自助努力したらどう?

>>988
うるさい黙れ

>>988
謙遜してるだけだろ
あの説明をあれ以上噛み砕いたら何も残らんよ

さっぱり噛み合ってない

噛み合せは大事だよ

それが、プロトコル

やり方そのもの書いてあるのにそれが「さっぱり」わからんようなの人間ですらないわ

おしえてくんのコピペに「さっぱり」の例があったなｗ

噛んで噛んで

回って回って

梅の季節

ネットワークプログラミング相談室 Port29
http://toro.2ch.net/test/read.cgi/tech/1351670708/

あとたのむ

Linuxがインターネットを作った。
Windowsは出て行け。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。