Posted on 2014年10月24日(金) 01:00
タイトルのとおり。
どうも、Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。
ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。
発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。
理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。
全くそのままでIPアドレス変えると動くようになります。
このあたりエラーメッセージを簡略化してたので(接続できませんでしたくらいに)、次からメッセージ入れようと思います。
基本ここで失敗はしないと思っていたので。
どうもSMB/CIFS周りはロバスト性に欠けてやっかいですわー。
Windows同士でも調子わるいときありますもんね。
無駄にSMB/CIFS周り(のバッドノウハウ)に詳しくなっていく・・・。
Posted on 2014年10月10日(金) 21:00
ネットワークプログラミングの基本中の基本。socket()関数があります。
(基本すぎて今ではもう直接使う人はいないのかもしれませんが僕は使います。。)
socket()関数は戻り値としてソケットのファイル・ディスクリプタを返します。
このソケットのファイル・ディスクリプタが何故か現代人には勘違いしやすいようで、うっかり0をエラー値だと思い込んでしまいます。socket()はエラーが発生したときには-1を返します。
これがうっかり間違えます。実際0が返ってくることがありますのでたまに動かないという分かりにくい不具合の原因になります。
わかっているのにうっかり間違えた例が以下のような感じです。本当に良く見かけます。自分も間違えますが・・・。
int fd = socket(AF_INET, SOCK_STREAM, 0);
if (fd <= 0) {
// COV_NF_START - we'd need to use up *all* sockets to test this?
startFailureCode = kGTMHTTPServerSocketCreateFailedError;
goto startFailed;
// COV_NF_END
}
おそらくポインタを返す時の失敗はNULLだろう、ハンドルを返すときのエラーは0だろう的な思い込みがあるせいではないかと思います。
WindowsのAPIは成功すると非ゼロを返すという仕様のものが多いので、そういう普段使っている環境での慣れもあるのかも・・・。
ちなみに上記のコードはGoogle Toolbox for Macの一部にありました。
同様に
if(soc){
close(soc);
}
みたいなミスもうっかりやりがちなのでお気をつけください。