アカウント名:
パスワード:
通信は通信機能のみに専念して欲しい。圧縮やら暗号化やら文字コード変換やらをしたがる通信ソフトは多いが、全部オフにしてそれらを別のソフトで行うのが吉。そうでないと障害が発生したときの切り分けや復旧が難しくなってしまう。この件、プロの方の意見をぜひ聞きたい。
クライアントは複数あるのでサーバーはそれらの多様な容貌に応えられないといけない。
障害が発生したときの切り分けや復旧が難しくなってしまう。
その通信ソフトが、それぞれの機能を別のソフトで行うのと同レベルの解析機能を用意していないのが悪い。
ネットワーク屋もサーバー屋もクライアント管理屋もやっておりますが...
ネットワーク屋単体としては、SMB2はファイル共有プロトコルでそもそもアプリケーションレベルの話になるので、TCP/UDPまでの疎通が確認できていればそこから先はサーバー屋さんにお任せって感じ。サーバー屋単体からしてみても、SMB2の枠内に収まっているのであればそれはそれでってところ。動かなきゃ一個ずつ切っていくだけだし。
一番困るのはクライアント管理屋で、「そのクライアント固有の障害か全体に波及している障害か」「何ができて何ができない」から推測していく形になるので、確かにたどり着くまでは長くなる。が、OS標準機能でついてきているものであれば容易にテストや機能のON/OFFはできるので、一度手法が確立してしまえばそれほど困らないかも。
むしろOS標準のライブラリで標準で圧縮送受信機能実装してほしいアプリ開発者が圧縮のこと考えるのとか面倒
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
通信は、 (スコア:1)
通信は通信機能のみに専念して欲しい。
圧縮やら暗号化やら文字コード変換やらをしたがる通信ソフトは多いが、全部オフにしてそれらを別のソフトで行うのが吉。
そうでないと障害が発生したときの切り分けや復旧が難しくなってしまう。
この件、プロの方の意見をぜひ聞きたい。
Re: (スコア:0)
クライアントは複数あるのでサーバーはそれらの多様な容貌に応えられないといけない。
障害が発生したときの切り分けや復旧が難しくなってしまう。
その通信ソフトが、それぞれの機能を別のソフトで行うのと同レベルの解析機能を用意していないのが悪い。
Re: (スコア:0)
ネットワーク屋もサーバー屋もクライアント管理屋もやっておりますが...
ネットワーク屋単体としては、SMB2はファイル共有プロトコルでそもそもアプリケーションレベルの話になるので、TCP/UDPまでの疎通が確認できていればそこから先はサーバー屋さんにお任せって感じ。
サーバー屋単体からしてみても、SMB2の枠内に収まっているのであればそれはそれでってところ。動かなきゃ一個ずつ切っていくだけだし。
一番困るのはクライアント管理屋で、「そのクライアント固有の障害か全体に波及している障害か」「何ができて何ができない」から推測していく形になるので、確かにたどり着くまでは長くなる。
が、OS標準機能でついてきているものであれば容易にテストや機能のON/OFFはできるので、一度手法が確立してしまえばそれほど困らないかも。
Re: (スコア:0)
むしろOS標準のライブラリで標準で圧縮送受信機能実装してほしい
アプリ開発者が圧縮のこと考えるのとか面倒