なうろーでいんぐ
キーボード↑↓
でもいいぞ
旧サイト形式へ帰りたい人
待機してたらこれだよ
2014年04月07日17時35分
なんか4月9日まで時間が出来た。
ちょっと調整して自重してたのに、まあええ。
CCENTの方は実機シミュレーション問題やった。
片手間でSQL本読む。従業員の欠勤テーブル
とかで連続欠勤集計する場合の対処とか読んだ。
個人的にはその日の前の出勤日を保持しておけば
連続休日判定をSQLで行う事を避けられると思う。
その前の出勤日ってのはどうやって出すか?
それこそphpとかのプログラムで算出するべき
なんだよなぁ、休日判定はお手の物。
餅は餅屋ってな。

別テーブルでカレンダー保持する場合、
カレンダーテーブルが必要な上に、
欠勤テーブルにはレコードが増えるのに対して、
上記方法ならdateフィールド1個増えるだけ。
そのフィールドが改変されているかのチェックも
集計前にphpを介してチェックすれば問題無い。
こうして考えると、ちょっと面白いと思った。
さて、そろそろ夕飯。
記事カテゴリ:未分類
突発的に調査
2014年04月06日17時01分
最近のLTEに感化されて、VoIP関連の調査と
サーバーセキュリティ側の調査。
VoIPについてはSIPとRTPが一般的に使われて、
特に気になるのがRTPだったので調査した所、
UDPにRTPヘッダとペイロード乗せる
との事で、ソケットプログラミングで可能っぽい。
perlで音楽再生を実装したプログラムも見つかった。
リアルタイム再生は魅力的ではあるが、
現状は使いどころが見当たらん。
あぁ、コールセンターでは結構一般的らしいね。
音声リアルタイム送受信でサーバー側に
データの保持もできるし、成程。

次にサーバーセキュリティだが、DoS攻撃関連。
特にDrDosやらが興味深い所。
結局のところ、帯域食い潰しのイメージ。
Syn FloodやらConnection Flood。
一般的対策では、

使用しないポートを閉じる。
iptables等でスプーフィングを遮断する。
syncookieをオンにする。

位かと、QoSでの対策は制限かかっちゃう
ので微妙と思われる。
無論調査をして最適な値が出るなら
使った方がいいけど。
これでも完全ではないというのだから奥が深い。
サーバー内部での対策だけだと限界が近いので
やはり別途対処用の機器を置いて対処させた方が
良いとか、また金か・・・理屈は分かるが。
余談だが、syncookieの問題点はLinuxが
吸収してくれているとの事。

同日 21:58
久々にエロゲネタキタな。
2013年クソゲーオブザイヤーinエロゲー板
http://www.nicovideo.jp/watch/sm23267427
大爆笑必至、クソワロタ。
記事カテゴリ:未分類
本日も安定の勉強
2014年04月05日19時01分
問題集1冊分終わろうとしている・・・。
LPIC読むか。
記事カテゴリ:未分類
問題集半分
2014年04月04日15時33分
300ページちょいまで進んだ。
今度はまた第三層関連。ルーター本大活躍。
引き続き頑張る。

同日 22:26
OSPFとEIGRPばっかりだった。
EIGRPはCisco機器だけの対応なのが勿体無い。
メトリックでロードバランシングしてくれるし、
トポロジーと隣接関係によるリンクステート型
の情報も保持してるまさしくハイブリッド型。

第三層での、ルーターが複数、スイッチも複数
の構成でIPでの負荷分散に対するイメージが
固まってきた。

ところで、L4スイッチってどうなのと検索したら
2004年時点で結構参考になる記事を発見
http://nosa.cocolog-nifty.com/sanonosa/2004/11/l4dsr.html
inとoutのレートは目から鱗だった。
こちらは第四層なので大雑把に言えば
ポート番号による負荷分散かな。
冗長化や別AS構成とかになると確かに別問題が
考えられるけど、まず個人じゃ買えないから
あんまり現実味が無い所。
中小企業で一般的なのはCCNAレベルだよなぁ。
下手するとそれ以下なんだろうなぁ。

同日 23:35
マルチキャストの概要をちょっと探った。
グループ申請したアドレスに対して
ルーター側がそれを検知しデータを送出する。
WAN側とのやり取りはほぼ出来ないと
考えていいだろう。
あくまでも同一LAN内で同じデータを
同時に送受信するのに使える技術かな。
記事カテゴリ:未分類