【艦これ】反撃!第二次SN作戦! E1攻略

仕事の関係上はじめるのが少し遅れましたが(昨日は猫と戦っていた)早速攻略を開始したいと思います。

既に歴戦の変態提督たちはE7に行って阿鼻叫喚しているそうな。
自分もちらっと見ましたがクリアできる気がしない・・・・

今回は春イベがぬるいと言っていた提督のご期待にこたえてかなり歯ごたえのあるイベントになっていそうです。
とはいえE1は去年の反省を踏まえてかいつも通りの難易度でした。




E1.jpg


※特に注意書きがない限り難易度は甲です

マップ概要
・駆2軽1あと自由編成のマップ。ただし一定条件でFにそれる?
・菊月を入れることで道中1戦でボス固定(ただし空母系がいるとCが優先される)

戦略概要
・航空戦艦を入れることで2順かつ制空確保で弾着
・水母を入れることで開幕の露払い

初めのマップということで小手調べ、いつもの水雷戦隊より若干自由
ここのマップで出撃するとE2以降はE7まで出撃できないので慎重な編成が求められる。
は菊月でルートが固定できる。固定しないとお仕置き部屋に連れていかれる可能性がありそこは無慈悲なル級
というわけで避ける一択。ボスはわるさめちゃん。重巡以上が入れられるうえ随伴艦に駆逐しかいないので特に苦労することはないでしょう。
この編成の弱点はT字不利を引くことですが、引いても余裕でボス撃破可

5出撃5撃破

最後は師匠が決めてくれました
「まぁそうなるな」

KanColle-150811-23261126.png




E1クリア後
KanColle-150811-22065404.png

E1開始前
KanColle-150811-23280946.png

こんなに時間がかかったのは疲労度をぬいていたからですね。
次は聯合艦隊。ここに出すと最終海域に持っていけないので熟考したいと思います。
スポンサーサイト

【艦これ】2015夏イベ前最終確認

はい。まさか広告出すやつとかおらんやろー┏(┏ ・´ー・`)┓

というわけで2015夏イベもいよいよ明日に迫りました。
作戦名は「反撃!第二次SN作戦」です。

おそらくifマップ(一部ソロモンでの戦線もあるようです。E3は南太平洋戦線)
そしてE4は飛行場がボスっぽいですね。13秋・・・飛行場・・・うっ頭が

二次とあるので当然一次があったわけですが。
それがヘンダーソン飛行場設営に当たると思われます。

南の戦線を維持するためにガ島あたりがちょうどよかったのでそこに飛行場を作ったのですが
当時はすでに暗号通信ががばがばでアメリカにもろばれ完成したところをいただかれたといった感じです。

その反攻作戦が13秋イベE4のモチーフであるヘンダーソン基地艦砲射撃です。
この作戦は戦術的には勝利しましたが、既に第二飛行場が完成していたので実質的にはあまり効果がなく
戦略的敗北を喫しています。

今回のイベントは改めて攻略してそこからの反攻作戦になるのでしょうか。

以上俄なりの解釈、多分大分間違ってます。




恒例のイベ前錬度さらし

艦隊錬度(20150809)

前回よりはましになりましたがまだ不安の残る錬度ですね。
計86隻主力になりそうなのをピックアップ、その他にも一応前半なら投入できそうな戦力がちらほら

装備の改修状況はめんどいのでパス
2号砲と大型砲をメインに改修しました。どのくらいかは各海域の攻略記事の時にお見せいたしましょう。

備蓄状況
KanColle-150809-16334199.png

ボーキ以外は20万以上を達成。大型たくさん回してこれなのでおおむね満足(なお大和
おそらくこれで足りなくなるということはないでしょう(慢心
不安なのはバケツですね任務消化時に結構使ったりしてしまったのであまり状況がよろしくないです。


前回のイベントからやったこと
・大和を出す
何の成果も得られませんでしたぁ!
20回以上回したんですが出ませんでした。はい大和がいないと無理な海域が出ないことを祈る

・牧場
蒼龍1隻のみ完了。他の空母も育てたかったのでこちらはあまり進まず。飛龍も結局牧場せず。
その他川内牧場を完遂し夜偵が2になりました。これで夜戦もばっちり
長門型牧場はある程度しましたがまだ4隻むっちゃんが残ってる状況
こちらを優先して艦隊のレベリングができなかったら本末転倒なのである程度で打ち止めにしました。
今回のイベントでレベリングしやすいところがあればそこでまた牧場したいと思います。

・戦艦の錬度向上
おおむね満足。少なくともレベル80以上に全隻しました。最低限最終海域には出れるレベルになったと思います。
その他空母レベリングもおこない雲龍以外は80以上にしました。

・天津風、磯風の育成
無事完了。おそらく水雷戦隊マップのE1に投入すると思われます

・装備改修
既に書いたとおり2号砲と大型砲をメインにすすめました。その他徹甲弾も少し



まとめるとある程度はできたが一歩届かないくらいですね。この一歩がどうなるか。
今回は過去最高の7海域からなるみたいなので大分楽しみです。

???「大艇ちゃんがいれな夏イベなんて余裕かも」

【艦これ】ダメージ計算機を作ろうその1

夏イベか告知され、7月のEOが復活した今みなさんいかがお過ごしでしょうか。

自分は1-5、2-5が終わり3-5と4-5が残り1回です。ここからが長いんですが。
5-5?いえ知らない子ですね

今回は艦これと銘打ってますが半分は技術的なお話。こんな簡単なことを技術といっていいか知りませんが
なんとなく仕事でPythonを使いそうなので勉強も兼ねて艦これのダメージ計算機でも作ろうかと

現在あるダメージ計算機はよくできているので2番煎じ感半端ないですが
(あまり調べてないのでもうあるという突っ込みはありで)

機能要件としては
・特定の敵に対してのダメージ乱数を出す
・特定の敵から受けるダメージ乱数を出す
・ワンパン撃破できる確率を出す
・ワンパン大破になる確率を出す
・etc...他に何かあればいってくれれば可能な範囲で実現

まあダメージを出すのはいいんですけど自分が今どれくらいの確率を引いているのかってのはやはり知りたいところ。
また大和型のような装甲が一見堅そうに見える艦はイベント深海で出てくるような艦から中途半端に装甲を貫いて
ワンパン大破になる率が高いのではないか(それ以外は中破ストッパーが働くのではないかみたいな

すでに個別に出している人とかもいそうですけどね。
まあ開発の練習なので実装する機能は何番煎じでもいいでしょう。

とりあえず環境構築+DBの情報をJSONで返すところまでで来たので悪戦苦闘のメモを

開発環境は
・CentOS7
・MySQL5.6
・python2.7.5
・django1.8.2
・django REST フレームワーク3.5.1
・apache2.4
・mod_wsgi-3.4-12

CentOS7からいろいろ変わっているみたいで
サービスの再起動とかはsystemctlコマンドになっているみたいchkconfig的なこともできるっぽい
入れ方もより分かりやすくなってました。

以下の順番で手を動かしてみた
・djangoを自前のサーバで動かした時
・django REST Frameworkを使った時
・apacheのモジュールを使った時

基本的にはREST APIを作成してその情報を元に処理する感じで書こうかと。
仕事でもAPI作りそうな感じがするので



ぶっちゃけ入れ方とかはいろんなところで解説されているし今さら何ですが参考にしたところを載せます。
・MySQL
CentOS 7にMySQL最新版をインストール

ここに書いてある通りに入れたら入れられました

とりあえず的情報を格納するテーブルを作る。

mysql>CREATE database KanCore
mysql>CREATE TABLE enemy
(
id INT(11) NOT NULL auto_increment,
name VARCHAR(64) NOT NULL,
type VARCHAR(10) NOT NULL,
Lv int(3) unsigned NOT NULL,
hp int(3) unsigned NOT NULL,
fire int(3) unsigned NOT NULL,
torpedo int(3) unsigned NOT NULL,
antiaircraft int(3) unsigned NOT NULL,
defence int(3) unsigned NOT NULL,
equipment_type VARCHAR(10) DEFAULT NULL,
PRIMARY KEY(id)
) ENGINE=innoDB DEFAULT CHARSET=utf8;

そのテーブル構造はないという突っ込みがありましたらどうぞ

データをこんな感じで入れる
INSERT INTO enemy (name,type,Lv,hp,fire,torpedo,antiaircraft,defence) VALUES('駆逐艦イ級','normal',1,20,6,15,6,5)
まああとでdjangoでモデルを定義するのでここでやらないでもいんですけどね。
既存のDBがあった場合にどうするかという参考になれば


・django
導入
wget http://peak.telecommunity.com/dist/ez_setup.py
python ez_setup.py
sudo easy_install pip
sudo pip install django

確認
pip freeze | grep django

これでdjangoが使えるようになりました。


開発
djangoではプロジェクトとその中に複数のアプリを持つことができる。
1つのプロジェクトの中で共通の設定(どのDBを使うかなど)を決めておき
アプリごとで例えばアクセスするテーブルを変えるとかがいいのだろうか。

とりあえず適当にdjangoディレクトリでも作っておく

その中でプロジェクトの作成
django-admin.py startproject KanCore

KanCoreディレクトリの中にさらにKanCoreディレクトリが存在する。
共通の設定はこの中で行う。
|--KanCore
| |--KanCore
| | |--__init__.py
| | |--__init__.pyc
| | |--settings.py
| | |--settings.pyc
| | |--urls.py
| | |--urls.pyc
| | |--wsgi.py
| | |--wsgi.pyc
| |--manage.py

settings.pyの中にmysqlの情報を入れる
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'KanCore',
'USER' : 'root' ,
'PASSWORD' : 'mysqlpasswd',
'HOST' : '',
'PORT' : '3306',
}
※ユーザーとパスワードはmysqlにあるものを使う
djangoでmysqlを使うにはmysql-pythonが必要なので入れる

sudo pip install mysql-python

なんか自分が入れた時はエラーが出て入れるのに苦労したが肝心のエラーログを取り忘れてしまった。
おそらく.soファイルがないとか言われるのでシンボリックリンクを張ってやれば解決できた気がする

以下をmanage.pyがあるディレクトリで行う
python manage.py migrate
python manage.py createsuperuser

何か想像以上に長くなったので続きは次回

OSPFその1

第9章 OSPFについて今週読んだ部分をまとめる

・Router ID
ネイバー関係を確立するときやDR・BDRを選出するときに使われる。
決め方はEIGRPの章で書いたとおり
基本的にはrouter-idコマンドで設定したほうが運用が楽
コマンドで変更してもOSPFの設定を変更しない限りSFPの再計算が走らないから?(自信なし)

・パケットの種類
Hello・・・お互いに生きているか認識し合ういつものやつ
DD・・・自身の持つLSAの簡易的な情報について交換する。これでお互いに必要な情報を確認する
LSR・・・DDで必要だと判断した情報についてネイバーに要求する
LSU・・・要求された内容を元にネイバーにLSAの情報完全な情報を渡す
LSAck・・・LSUを受け取ったことによる返答。これによりLSUが相手に届いたことが補償される

・隣接関係を構築するまでの手順
1.Helloパケットを3wayハンドシェイクと同じ手順で隣接ルータを認識する(以降定期的にHelloパケットを交換する)
DR/BDRの選出が必要ならここで行う
2.DDパケットをお互いに交換しマスター/スレイブの関係を構築
3.経路情報の交換。お互いに持っている情報が一致したら隣接関係の構築終了

・ネイバーの状態の種類
Down・・・ネイバーを構築する前もしくはネイバーとの隣接関係を維持できなくなった場合この状態になる
Attempt・・・NBMAのような特殊なネットワークでこの状態になる
Init・・・Helloパケットを交換し始めた状態
2-Way・・・Helloパケットの交換が完了した状態
ExStart・・・相手がDRもしくはBDRのときこの状態に移行。どちらが主導権を握るかのmaster/slaveの決定を行う
ExChange・・・DDパケットの交換を行う。マスターになったルータから送る
Loading・・・必要なLSAの情報を取得する段階
Full・・・必要な情報を全て交換し終え自身の持つDBと相手のDBの情報が一致した状態

Helloパケットの交換に関して
224.0.0.5のマルチキャストアドレスに定常的に流す

4つの役割
・隣接ルータを探す
・隣接ルータの設定値に問題がないか確認
・お互いに疎通できるか確認
・ヘルスチェック

以下が一致しないと隣接関係は組めない
・認証
・同じサブネットに属する
・同じエリアに属する
・同じエリアタイプ(後述)
・Router IDが被らない
・タイマー値の設定が同じ
※MTUの値がここではチェックされないがDDパケットの交換時にこれがあっていないと不整合が起きるのでいずれにせよ合わせる必要がある。

DDパケットに関して
ヘッダーには以下のフラグがある
・MS・・・自身がマスターだと認識している場合はここにフラグを付ける。このパケットを交換し始める場合は自身をマスターと思うので最初は必ず立つ。その後Router IDを比べて大きい方がこのフラグを立てたまま。slaveになると立たなくなる。
M・・・Moreフラグ。さらにDDパケットを交換する必要がある場合はここにフラグを立てる。DDパケットはマスターからしか送らない。slaveはレスポンスのみできる。slave側でさらにDDパケットを送りたいときにこのフラグを立てることでMasterはDDパケットを送出し続ける
I・・・Init、その名の通り初期にMaster/Slaveを決めるまではこのフラグが立つ。

DDパケットの中にはシーケンス番号を入れられる。これは32ビットで大きい方がLSAの情報が新しいことを示す。
これが一致していれば情報に変わりがないことを示す。

LSUとかに関しては前述以外のことは特にないので省略

今回はここまで。本当はDRのところあたりまでは読みたかった

EIGRP

追記予定

EIGRP概要




EIGRPのメトリック




EIGRPのパケット




EIGRP named mode




EIGRPその他機能
RouterID
OSPFみたいに使われるわけではないがルーティングループ防止などの役割がある。決め方はOSPFと同じ
数値的には32ビットの値(IPアドレスと同じ形式)
1.router id コマンドの結果
2.ループバックアドレス
3.インターフェイスのアドレスの中で一番大きいもの
ネイバー間で同じ値だと再配布などで不都合が生じる

非等コストバランシング
フィジーブルサクセッサーは通常ルーティングテーブルに載らないがこの設定を入れることで
乗るようになる。またコストが低い方が優先的に使われる

Add-Path Support
ハブ&スポーク形式の構成においてDMVPNを組むことがあるが
マルチホームで構成すると片方のルートしか広報されずそのルートがダメになった時再計算が走るという問題がある。
これを防ぐためのコマンドいわゆる等コストバランシング

Stubルーティング
同じくハブ&スポーク構成の時たいていはスポーク側はそれ以降にEIGRPを動かしていないので
スポークがネクストホップのルートがおちた時クエリを投げる必要がない。(クエリは再計算で違うルートを探すときに使う)
そのことをハブ側に伝えるためのコマンド。
いくつか種類がありそれごとで伝えるものルーティングテーブルに乗せるものが代わってくる

Routeサマリー
ネクストホップに当たるルートが複数ある時それをまとめることができる
ルーティングテーブルにはNull0とのり、ここに一致したものはドロップされるが
更に詳細なルートがルーティングテーブルに乗る。ルーティングテーブルに一致するものが複数あるときは
詳しいものが優先されるのであまり気にする必要がない。
またADの値はデフォルトで5のためあまり変える必要がない。しかし学習したルートでAD5のものがあると
あまりよろしくないのでその時は変える。ただし255はバージョンによって挙動が代わるので非推奨

パッシブインターフェイス
そのインターフェイスにつながるセグメントがEIGRPをしゃべる必要がない時設定する
こうすることでHelloパケットを投げなくなり帯域の消費などを抑えることができる。

Gracrful shutdown
Helloパケットに入れるK値を255に設定することでルートの広報を無効にする。
あまり使われない?shutdownコマンドだけで設定できるのでお手軽だけど

認証周り
隣接関係を構築するのに不正なルータなどが入らないように設定する。
現在認証の強度は上がってきておりSHA-2が使われている

デフォルトルーティング
通常デフォルトルートの広報はコマンドレベルサポートしていないがいくつか方法がある
1.ip-default-network ・・・クラスフルネットワークの単位で広報可。通常は使われない
2.static routeの再配布を使う・・・一番スマートなやり方か
3.network 0.0.0.0を使う・・・全てのインターフェイスでEIGRPを有効にする。そこでデフォルトルートの設定を送信元インターフェイスを指定することでDirectory Connectedとして認識され広報される。正直よくわかっていない。教えてエロい人

EIGRP OTP
CCIEの範囲外っぽい。通常IPはネットワーク部とホスト部から構成され。密接な関係にあるのでそれを切り離して運用しようという話。RLOC(場所を示す。普通はサイトの入り口のIP)とEID-Prefix(ホスト部に当たる)に分かれる

EIGRPフィルタリング
広報するルートに制限をかけようという話。いくつか方法はある。

EIGRP Offset Lists
特定のルートにコストを盛る(delayを盛る感じか)

その他にルーティングテーブルからルートを削除することができる
トポロジーテーブルは変わらないのであまり意味がない?
ネイバー関係を削除するコマンドがありそっちは再計算が走りそう
最新記事
カウンター
月別アーカイブ
カテゴリ
リンク
RSSリンクの表示