ニコニコシェア R1.1.0をリリースしました

R1.1.0です。

Firefox4以降に対応しました。
現在最新のFirefoxは5となっており以後6週間程度の単位で頻繁なバージョンアップが繰り返される予定ですが、少なくとも当面はこれらのバージョンアップにも対応しているはずです。

何かありましたらコメント欄までお願いします。

Posted by ROCA Comments (3)

ソフトバンク回線のパケットロスがほんとーーにひどいのかTCPでも確かめてみた

前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。
本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。
ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。以下、その結果。

続きを読む »

Posted by ROCA Comments (2)

ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた

追記書いてます。

—

#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか？

という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。

テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。

テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。

テストサーバー

1. www.yahoo.co.jp(ロケーション: 東京 丸の内 ブロードバンドタワー)
2. www.google.co.jp(ロケーション: 恐らくアメリカ西海岸)
3. テストサーバー1(ロケーション:アメリカ FremontにあるVPSサーバー)
4. テストサーバー2(ロケーション: さくらインターネットのVPSサーバー。設置場所は不明だが国内)

テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。

結果は以下の通りである。

テストケース1: PM9時台に実施

テストケース2: AM2時台に実施

比較のためWi-Fi(回線はフレッツ光)も付記している。

まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。

ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。

僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。

ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。

Posted by ROCA Comments (41)

ニコニコPodder R1.2.5をリリースしました

Posted by ROCA Comments (28)

auのEZWebがそろそろ終了しそうな件

先日auからEZWebに関わる以下のようなアナウンスがなされた。
KDDI au: EZfactory

EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。
これによる主な変更点は以下のとおりです。

＜主な変更点＞
・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。
・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。

他にもCookie仕様の変更などがあるのだが注目すべきは、「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」という点だ。

以前書いた記事も参照して欲しいのだが、

続:携帯で端末ID詐称は可能かもしれない話
(追記) 続:携帯で端末ID詐称は可能かもしれない話

EZWebつまり日本のケータイECを支えているケータイID(端末ID、サブスクライバーID)は単純に契約者または端末ごとに振られたIDをHTTPヘッダーに載せて通知して、WEBサイト(例えば公式サイトでの決済や課金など)ではこれを元に契約者を特定しているだけなので単にインターネット上で実現するとすぐに偽装や詐称されてしまう。
そこで再掲になるが、auに限らずドコモやソフトバンクでも以下のような脆弱な要件を満たさない限り、ケータイIDが偽装・詐称されずに正しく利用されていることはサイト側(サービスプロバイダー)では見分けが付かない

(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと

但しauではEZ番号はゲートウェイで付加されるのではなく端末側から直接送信されているようなので、上記の三原則であれば1と3でしか担保されていない模様だ。

EZ番号を使用したケータイECに対応するのがEZブラウザであり(ドコモであればiモードブラウザ)、PCサイトビューアはEZ番号は発信しない単なるフルブラウザである。
しかし上記条件にあるようにEZブラウザ以外のブラウザやアプリからEZブラウザと同様のIPアドレス帯域に接続でき、かつEZ番号を偽装できるならこの日本独自のケータイECの仕組みは崩壊することになる。
であれば果たしてEZブラウザとPCサイトビューアのIPアドレスが統一された後、PCサイトビューアで偽装が可能になってしまわないのか。

この疑問に早速、徳丸浩氏が実験を行い結果を公表された。

EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点

上記のように、現状のPCサイトビューアでは、EZ番号が追加できるほか、W52TではUser-Agentも変更できます。2011年秋冬モデルの仕様はわかりませんが、上記と同じ仕様である場合、EZ番号の偽装が可能になります。

2011年秋冬モデルでもEZブラウザにJavaScript機能が搭載される予定はないようですが、JavaScript機能があるPCサイトビューアのIPアドレスが統一されることで、結果として、事業者ゲートウェイを経由する端末の中に、JavaScript機能を搭載したものが含まれる状態が生まれます。このため、JavaScriptを悪用した攻撃の可能性が生じてきます。具体的には、JavaScriptによるEZ番号（サブスクライバID）の偽装、DNSリバインディング攻撃などの可能性が生じます。

IPアドレス帯域の統一は7月から、また2011年秋冬モデルからの変更と言うことなので、実際にどうなるかは7月以降の検証を待たなければならない。
しかしもしPCサイトビューアの仕様が大きく変わらないのであれば、EZWebでのあらゆる課金や決済は(たとえ暗証番号があるにせよ)偽装放題と言うことになる。
「でもそもそも他人のEZ番号なんて分からないのでは？」という疑問もあるだろう。しかしEZ番号は端末で「送信する設定」(デフォルト)にしてあれば勝手サイトにであっても常にEZ番号は送信されているのである。
つまり例えば決済や課金など関係ないケータイサイトを運用していても、実はEZ番号は大量にこれまでに入手可能であり、 ユーザー登録の必要なサイトであれば名前や住所などと紐付けられているかも知れないし、そもそも氏名など分からなくとも、ランダムにリスト化されたEZ番号を使って総当たりで詐称攻撃することも可能になるだろう。たとえ暗証番号があるにせよ、また3回間違えるとそのアカウントがロックされるにせよ、最低数百件程度のリストがあれば暗証番号を固定して次々に試せばそのうち幾つかは楽に認証を通ってしまうだろう(これはとてもよく知られた初歩的な攻撃手法に過ぎない)。
知らぬ間に公式サイトで勝手にデジタルコンテンツを大量に買っていたことになっていた・・ということも十分起き得るのである。

率直に言って、何故auがこんな仕様変更を簡単に行ってしまうのか、全く理解できない。そもそもauは、上記のような「脆弱な基盤」に支えられたケータイIDというものを理解していないのではないか。

以前僕はこのようにブログに書いたことがある。

三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・？ 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。

全ては2011年秋冬モデルの発売を待たなければ本当のところは分からないが、まさしくこの懸念が当たる際にいるのかも知れない。

Posted by ROCA Comments (4)

ドコモもauも「これまでのケータイネットはインターネットではなかった」と言い出した背景

ここしばらくキャリア各社の新製品発表なども続き、その中で時あたかもドコモ・auで立て続けに同じような興味深い発言が続いた。

ネットの大海原に出るための「再定義」――ドコモ伊倉氏に聞くスマートフォン時代の“パラダイムシフト”戦略（後編） (3/3)

では、なぜキャリアがスマートフォンを推進しているのかというと、まずフィーチャーフォンの垂直統合のモデルから、そうならないところに移ることが重要である、ということがあります。それをドコモが積極的にやることによって、インターネットの世界や新しい世界をきっちりと理解し、その中でクラウドを意識して、サービスの設計をする。将来的にクラウド系のサービスをやる前提として、スマートフォンを推進しなければならない。

【WIRELESS JAPAN 2011】 KDDI田中社長、「なんちゃって」から「真のインターネット」へ

「この10年は、携帯電話の10年だった。また3Gと定額の時代でもあり、その中で、なんとか（パソコン向けの）インターネットの価値を小さなデバイスに取り込む、『なんちゃってインターネット』の時代だった。非常に良い時代だったと思う」と表現した

微妙にニュアンスは異なるが、ともに「もう携帯電話に独自ネットを閉じ込められない」危機感を有しているのがよく分かる。

キャリアから見た場合には見方が異なっていると思うのだが、この10年は携帯電話のCPUなど性能の問題で「なんちゃってにせざるを得なかった」という意見のようだ。
しかし当然理解されることとして、日本のガラケーは既に何年も前からスマートフォンだったという人もいるように(僕はそう思わないが)、またフルブラウザはもう5年以上も前から登場しているし海外ではスマートフォンはやはり5年も前から普通に使われていたことから考えて、単にここに来て「各キャリアが従来の携帯網ビジネスを手放さなくざるをえなくなった」一種の敗北宣言と捉えられよう。

日本のキャリアがこれほどまでに垂直統合モデルによって過分な利益を享受しモバイルECをここまで発展させられたのは、これまでも何度か書いている通り「閉塞された携帯網」でのみネット接続を許し、その中でのみコンテンツの利用をユーザーに許し囲い込んできたからだ。
まさしく「なんちゃってインターネット」であったわけだ。

参考:
iモードはダイヤルQ2から始まった
“ガラパゴス”の定義とは

約1年前に「SIMロック解除よりもアクセスポイントの解放こそが有効だ」という記事を書いた。そこではSIMロック「だけ」ではなく、閉塞した携帯網ではなく、インターネットへ開かれたアクセスポイントの解放が必要だと書いた。実のところ、こうしたコンテンツを囲い込む閉塞した携帯網でビジネスを続けてきたのは日本のキャリアだけであり、だからこそ寡占状態を生み出せて成功もしたのだが、世界的にはこうした垂直統合の名の下の囲い込みビジネスは珍しい。他国ではそもそも携帯網とはインターネットへ直結されている、携帯網とそれ以外の違いはなかったからだ。

では従来の携帯網をそのままスマートフォンに適用すればよいかというとそれも難しい。モバイルECを支えているケータイID(端末ID)はセキュリティ的には非常に脆弱であり、閉塞した携帯網でしか機能できない。
またもともとスマートフォントは、キャリアが企画して作り上げたものではない、いうなれば海外直輸入の「黒船」であるのでそうしたビジネスモデルが構築できない。

そこをどうするかを各キャリアは今必死に考えているところであり、それを示すのが上記の記事でもあるわけだ。
そして長期的に見れば、各社とも認めているとおりこのビジネスは衰退せざるを得ないだろう。そして否定はしているものの、各キャリアはやはり「土管屋」として、これまでのようなコンテンツビジネスからは市場からは追い出され回線費用のみで稼がざるを得なくなっていくだろう。
それがこうした弱気さともあるいは前向きとも捉えられる発言の背景なのだと思う。

では今後誰がケータイやスマートフォンのコンテンツ市場を担っていくのか。
それこそまさに「本当のインターネット」の世界が決めていくことであろう。これはここに来てようやく日本のケータイがインターネットに繋がりつつあるのだということだ。
これからのケータイネットにおいても、少なくとも現在主流のYahooなどのポータル勢やまたゲームを中心にしたSNS勢、またはFacebook、Googleといった海外勢が多くを担っていくことになるだろう。

では果たしてこれまで各キャリアと組むことで謳歌してきたコンテンツプロバイダー(C/P)各社はどうだろうか。
先日このような発表もあった。

「スマートフォンでiモード」を普及の「武器」に──ドコモ夏モデル発表

今年冬には、スマートフォン向けにiモードの課金・認証の仕組みを導入。iモード端末ユーザーが「マイメニュー」をそのまま引き継ぎ、iモード公式サイトコンテンツをスマートフォンでも利用できるようにする

さもあらん、という感じだが、このiモードコンテンツのスマートフォン対応というのが何かはよく分からない。そもそもコンテンツとしてはスマートフォンへ完全に作り替えなければならないのでこれまでのケータイ向けノウハウは全く役に立たないだろうし、また課金などの仕組みもiモードから移行させるのだろうが、これがうまく行くのか(セキュリティ的にも)よくわからない。
実のところ、個人的にはこれはドコモが主体で行いたいと考えているのではないだろうと思っている。つまり売り上げ低下の激しい従来のC/Pからの激しい追求・要望があった故ではないか。
ではうまくいくだろうか。
一つ思うのは「檻の中で飼われたライオンは野生では生きられない」ということだ。課金の仕組みもお仕着せのユーザー導線も何もないところから競争を勝ち上ってきた「真インターネット」組に太刀打ちできるとは到底思えないのだ。

キャリアが望もうと望むまいと、あるいは如何に抵抗しようと徐々に「土管屋」へ近づくのは時間の問題だ。つまり焦点は既に土管屋にはなく、果たして(主に海外)メーカーがまたは他のサービス事業者がどのような施策を打ち出しつつあるかに注目した方がよい。
二年後、恐らく日本の携帯業界は今とは全く別の力関係が存在していることだろう。

Posted by ROCA No Comments

iPhone 3Gの電池が膨張してケースが割れたけど、AppleCareサービスで無償交換してもらえた話

検索する限りは同じ現象に遭っている人はいなさそうに見えたんですが、もしかしたら遭遇する人がいるかも知れないので、記録のために残しておきますね。

先日ふと今やテスト用と化したかれこれ2年半ほど使っているiPhone 3Gを掴んだ時に違和感を感じてケース裏を確認したら、ケースの真正面に縦向きに大きなヒビが入っているのに気付きました。

林檎マークからiPhoneロゴのところまで約10cmぐらいの比較的大きなヒビでした。
ケースの裏側も普通は真っ平らだと思うんですが 、こころなし林檎マークを中心に少し盛り上がって平らではない感触。
瞬間的に「電池膨張してケースが内側から割れた？」と感じました。
普段常用しているのは3GSなのですが、3Gは開発テスト用に使っていたのでこれはこれで無くなると困ります。かと言って使い続けたら、ニュースで時々聞くようにいつか爆発なんてことになったら大変です。
ということでサポートに連絡を取ってみることにしました。

まずは近くにソフトバンクショップがある(3Gは発売月にそこで買った)のでそこへ持ち込み。
んでお兄さんが言うには、

• ソフトバンクショップでは最新機種で保証期間中なら無償で交換できるが、3GSや3Gについては受け付けていない
• 原則として外面上キズがある場合には交換料として一律22,000円頂くことになる

との返答。Apple Careにも入っていないので当然保証期間は切れています。
ただ、ソフトバンクショップが頼りにならないのは最初から想定内。
とりあえずソフトバンクのサポートポリシーを聞き出してから(要するにアップルとの契約上、サポートについては何も出来ないとのこと)、直接アップル・サポートへその場で電話してもらって担当へつないでもらうように頼みました。
日曜だったので少し時間はかかりましたが、 アップル・サポートへ事情を伝えてもらい、どうも電池の不具合らしいということは理解してもらえたようです。
但しこうした製品瑕疵(多分事故に関わる問題という意味かな？)については上位部署につながないといけないのだが、当日は日曜だったため混んでいて電話が繋がらず、後日あらためて連絡して欲しいとのこと。
受付番号をもらってその日はソフトバンクショップを後にしました。

翌日連絡すると、その上位部署というのはAppleCareサービスだったようです。通常のサポート部署とは違うんですね。
昨日対応できなかったことをお詫びされながら、まず「怪我や被害はでていないか」「ケースやPCなどが破損したりしなかったか」などこちらの被害がなかったかきめ細かく聞かれました。
その後再度裏面の様子や利用環境、PCとの接続形態なども細かく聞かれ、結論として

• 直接確認しないと何とも言えないので(そりゃそうですね)、配送業者を手配するのでiPhoneと接続していたUSBケーブルを送って欲しい
• 原則修理と言うことは行っていない。出来る対応は交換のみとなる(シリアル番号が変わるという注意があり)。
• 本来保証期間外だが、無償交換できるかどうかは現物を見てみないと現時点では何とも言えない
• 早めに現状を確認できると思うので可能であればヒビの様子を写真に撮ってメールで事前に送って欲しい

とのことでした。
実は開発・テスト用に3GはiOS3.1.3に止めており、仮に交換となった際にiOS4.xに上げられていると困るためどうなるかも質問したのですが、折り返しで「3GならiOS2.xで交換される」との回答をすぐもらえたので手続きをお願いしました。
3Gは復元でデータ初期化してから、木曜日に配送業者が引き取りに来ました。

その後連絡はなかったのですが、翌週火曜日に突然宅配便が来て、中には交換された新品(なのかな？)の3Gとやはり新しく交換されたUSBケーブルが入っていました。つまり「無償で交換」という判断をしてもらったということなのでしょう。
但し詳細について連絡も詳しい説明書なども入っていなかったので、後日こちらから連絡して(何かあったら連絡下さい、とのことで内線番号まで聞いていた)、折り返しでどういう判断をしてもらったかを聞きました。
実のところ(少なくとも日本では？)AppleCareサービスでは故障品の中身を空けて原因を調べると言うことはしないそうで、ただ外見上や利用状況から判断して「自然発生であったこと」「ユーザー瑕疵は無さそうなこと」「このまま使えば事故に繋がりかねないと判断したこと」などから部署内に在庫もあったため無償交換をしてくれた、ということのようです(ただしあまりはっきりとした判断を示されず、上記は少し曖昧な話からの僕の想像で補っています)。
また「常に出来る対応とは限らない」点は念押しされました。

ということで一件落着。3Gは新しくなったし(と言っても常用じゃないしそれ自体にはあまり意味は無いんですが)、テスト用の環境も簡単に戻せたので満足です。
アップルのサポートの評判は僕はよく知らないのですが、全般的に非常に親身で丁寧、かつ迅速な対応と判断でしたので少なくとも今回に限っては大満足でした。素晴らしいサポートが体験できました。
もちろん常にということではないかも知れませんし、特に今回は事故に繋がりかねないという点が大きかったのだろうとも思います。

めったにあることでは無いと思うのですが、もし電池が膨張などした場合には大変危険ですので、すぐにアップルのサポートへ連絡されることをお薦めします。上記と同じ対応が取られるとは限りませんが、爆発事故など起きてからでは遅いですからね。気を付けましょう。
本当は使わない時はケーブルから外して時々は放電もしておくのがいいんですよね。開発に使っているとなかなか難しいんですけどね。

Posted by ROCA Comments (3)

続々: 楽天銀行アプリのセキュリティについて – 結局UDID送信は中止しないし使用理由開示も行わない

前々回、前回の続きをご報告したいと思う。
かなりあれから時間がかかったが、結論としてはシンプルで楽天銀行および楽天CERT・楽天グループとしてはUDIDの送信は停止しないし、また何故送信しているか、どのように利用・管理しているか は「当行不正取引防止システム運営の機密事項」のため一切開示しないとの結論であった。
以下、その詳細。

続きを読む »

Posted by ROCA 1 Comment

[改訂版] iPhoneアプリのSSL接続をパケットキャプチャする方法

前回記事のはてブコメントで教えてもらったんですが、Burp Proxyというプロキシー型キャプチャソフトがあるそうです。
で実際使ってみると、これいい！お手軽ですね。Fiddler2と違ってiPhoneアプリでも利用可能です。
ということで改訂版をまとめてみますよ。 一応再度のまとめにしますので前回と被る部分もありますがご了承下さい。

なおやはり再度の補足になりますが、セキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。

続きを読む »

Posted by ROCA 1 Comment

ニコニコPodder R1.2.4をリリースしました

R1.2.4です。ご報告も頂きましたバグFIX版となります。

■ ブラウザ統合認証において、IEの保護モードを切り替えていたりIE6以前からのアップグレードを行った場合IEでの認証でエラーが発生する場合があった問題を修正

コメント欄でご報告頂いていました。
状況によりIE8などでのブラウザ認証統合が使用できていませんでしたので修正しました。

■ nicoPodder.iniでファイル名パターンを変更した場合に変換エラーになるなど複数の不具合が発生する問題を修正

こちらもコメントで指摘頂いていた点です。

■ iTunes登録部分のコードを全面的に書き直しました。エラー内容もより詳細に表示されるようにした他、iTunesとの連携エラーのハンドリングも強化しました

実はこれまでニコニコPodderのコードはかなり書き直してきているのですが、唯一手を出せず複雑の一途を辿っていたのがiTunes登録関連でした。
まだiTunesへの登録時にエラーが起こる場合があるとのご報告を受け、実際にはiTunes側の問題であるようなのですが、安定版として意宇でリスクもあるのですがこの際ですので全面的に書き直しを行い、より詳細なエラーが表示できるようにしました。
テストは十分に行ったつもりですが、お気づきの点があればお知らせください。
また情報登録のタイミングを変更し、エラーが発生しても再度実行すれば最終的にはできるだけ完了するように変更しました。これにより、実際のエラーは回避できないかも知れなくとも、自動実行などで再トライすれば最終的には完了する可能性は高くなったものと思います。
但し何分当方ではそうしたエラーが出ていないため、これまでお困りの方がいらっしゃればぜひ試して頂いて、これまでとの違いなどご報告頂けると助かります。

以上です。何かありましたらコメント欄までどうぞ

Posted by ROCA Comments (30)