つれずれなるままの開発日記(最近はFlexばかり..)

Archive for the ‘ActionScript’ Category

そこそこバグ修正やら問題対応やら、追加機能を行い、Rev65をGoogle Codeに上げました。
これをもうちょっと、テストしつつ、バージョンを 0.6 にしようとおもいます。

追記：
————————————————————————————————————-
バグがありましたので、Rev66にしました。
やっぱり、ちょっと気がついたレベルで直したのがよくなかったとおもいました・・・・
————————————————————————————————————-

さて、今回の対応ですが、大きく分けて以下の対応があります。

１） 送信処理で画面の方が固まってしまうことがないようにする対応。

こちらは、AIR2 SecureSocket とgmailの組み合わせで非常に起きてしまっていました。
gmailはデータの書き込み(flush()) 処理に時間がかかるようで、そこで画面の方まで固まってしまいました。
そこで、一度ByteArrayに出力してから、サイズを細かく分割して、さらにTimer処理にしました。
（このあたりの、ノウハウが今ひとつわからず、四苦八苦です。)

このサイズを変えるのは

SMTPSender.setParameter(SMTPSender.BUFFER_SIZE,1024*20);

デフォルトは、16234です。
こちらTLSに関連する数字なのですが、実はこの対応をしているうちに、3)の問題が解決しているっぽいことが判明。
根拠が正確にわからないので、真偽はさだかではありませんが、明らかに問題がでていたのが、いまのところ再現しなくなりました。

また、ネットワークが早く、小さいメールしか送らない場合で、この機能を使いたくない場合には、

  SMTPSender.setParameter(SMTPSender.ENABLE_BUFFER,false);

２） 接続がうまくいかなかったときの対応の強化。

こちらも SecureSocketとgmailで初めのネゴシエーションが異常に時間がかかります。
こちらを接続命令を出してから、5秒でタイムアウトとしていたのを、
接続が完了してから、10秒以上サーバから 220のステータスがかえってこない場合にタイムアウト処理にしました。

ちなみに、この時間を変えるのは

 SMTPSender.setParameter(SMTPSender.CONNECTION_TIMEOUT,5000); // default 10000 -> mean 10 sec

３） gmailとas3crypto を使ったときに、添付ファイルが大きいと接続が切られてしまうことの改善。

こちらは、１）で記述したので省略。
ただし、as3crypto 1.3 のバグを発見。Socketをcloseしたあとにflush()をしていたので、エラーが起きていた。
ごくまれに起きる。すでにquitしたあとに、起きているエラーなので、無視しても問題無いと思えば問題無い。
ソースを見るとtrunkでは直ってるぽいです。

４） STARTTLS への対応

// comment out
// use plain socket
//sender.setParameter(SMTPSender.SOCKET_OBJECT,new TLSSocket());

sender.addEventListener(SMTPEvent.SMTP_START_TLS,startTlsHandler);

public function startTlsHandler(event:SMTPEvent):void{
	var sock:Object = event.socket as Socket;
	var tls:TLSSocket = new TLSSocket();
	sender.setParameter(SMTPSender.SOCKET_OBJECT,tls);
	tls.startTLS(sock,"your.smtp.host.name");
}

みたいな感じで。
みそは、初めは通常のSocketを使うのですが、STARTTLSで、socketオブジェクトを設定し直す必要があります。
そして、その後、startTLSメソッドを投げます。”your.host.name” はどこまで意味があるのかは不明です。(as3cryptoをそこまで見切れていません。）
あとは、使い方は変わりません。

５） Thunderbird でサブジェクトが文字化けすることのバグ修正。

Thunderbirdのながーいサブジェクトが文字化けしていました。（MIMEで改行が入る場合）
こちらも修正。
むかーしは、WebMailがたいていおかしくて、すべて１行で書いてしまうのがよかったのですが、
今はどんなかんじが現実問題ないのかがわからないのですが、見ている感じThunderbirdが厳しいみたいなので・・・・・

あと、細かいあれこれを・・・・・ちょこちょことやっています。

さて、いろいろやってみて、思ったことは、
AIR2のSecureSocketよりも、 as3cryptoの方が何かと都合がいいなと感じました。
それは、まず、なぜがかas3crypto のほうが早い。体感なので、厳密にはわかりません。
とくに、gmail の接続がSecureSocketではうまくいかないことと、成功しても遅いことが多々あるのです。
あとは、画面処理に影響が少ない気がします。
どうしてもSecureSocketのflush()処理で、画面がカクカクしてしまうのです。
Timer処理と、一度に書き出す量(buffer size)を調整することが必要な気がします。
(as3cryptoでは今のところ、それはありません。）

STARTTLSみたいに、途中からTLSという接続もできないのですが、as3cryptoなら可能です。

前回、課題をのせましたが、もうちょっと詳細に問題が見えてきました。

１）SSL/TLSへの対応
この問題の一部で、SecureSocketを使ってgmailの465(いわゆる smtp over ssl )につないだときに、なぜか今まで接続に失敗することがあった。

実はこれ、私が明示的に作っていたタイムアウトで切断されていだけでした。
たとえば、SMTP over SSLが必須にも関わらず、通常のプレーンなSocketでつないでしまった場合も考えて、
接続に成功しても、220のステータスがある時間（デフォルトで5秒) 帰ってこなければエラーにしていたのですが、gmailだと接続に時間がかかるときがあるらしく、
この制限に引っかかってしまっていました。
まさかそんなにかからないと思っていたので、疑ってもいませんでした。（とほほ・・・）
あと、その設定を変えられるようにしていませんでした。

なので、この制限のデフォルトを伸ばすこと(10秒）と、設定を変更できるようにします。

２）大きな添付ファイルなどをつけた時に遅いこと。
こちら、以前はBase64が遅いといいましたが、こちらもおそいのですが、
それ以上に、SecureSocketのflush()メソッドが遅いことがわかりました。
実際 800kのファイルを添付するのに、私のPCで1秒弱かかっていますが、それをBase64したあとに、
writeUTFBytes()して、flush()するのですが、
このflush()だけで、8秒弱かかっています。

ただし、原因はわかりません。ネットワークの上りがおそいのでしょうか？
それとも、大きなデータを一括でflush()してはいけないのでしょうか？（といってもそれほど大きくないともおもうが・・・）

ただ、この8秒という時間が、「応答なし」という状態を作ってしまうのはちょっといただけないなと。

このあたりを修正して、近いうちにバージョン 0.6としてアップできればと思います。

前回、記したgmail port:587 での送信をas3cryptoを使用し試みた。
このために、airxmailもstarttlsコマンドに対応をした。

結果は・・・・・
SMTP over SSLと変わらず。
もしかして、ポートが異なれば違う動きをするかも？と淡い期待をしてみたが、やはり結果は同じだった。
メールサイズが大きくなると、エラーになってしまう。
（小さい物だと問題無いのも同様。）

まあ、結果的に同じ結果になったが、ほかのサーバでうまく動くケースもあるかもしれないので、
ただ、せっかくなので一応、後でgoogle codeのほうにコミットしておくことにはします。

airxmailもいろいろと使ってもらえるようになり、いろいろな人から意見やら、バグ報告やらいただいた。
アメリカやイギリスからも報告をいただき、本当にありがたいことです。

そして、問題もある程度見えてきました。

ただ、説明が不足している部分もあるようなので、時間があるときにデバッグの方法なんかも今後記述したいとは思います。

さて、現在の課題だが、以下の２点だろう。

１） SSL/TLSへの対応。
２） 大きな添付ファイルなどをつけた時に遅いこと。

問題１は、as3cryptoやAIR2のSecureSocketに責任を丸投げしてしまっているところがあったので、
あまり、作るときに真剣に考えなかったが、やはり何らかの対応は必要のようだ。
特に、SMTP over SSL では今のままの形になるが、STARTTLS( いわゆる Port : 587を使う）には何らかの対応が必要だろう。
（といっても、SSL/TLSライブラリを作ることからは始めないので、やはり今のas3cryptoなりの外部ライブラリで対応できなければ厳しい。）
現在、どうしてもgmailのSMTP over SSLで、as3cryptoを使うと通信の途中でエラーが起きてしまうのだ。
しかも、添付ファイルをつけた時に発生する。
また、AIR2でSecureSocketを使うと、今度はなぜかたまに接続に失敗する。接続に成功すれば、こちらは今のところ、1Mクラスの添付ファイルでもおくれるようです。
ただ、どうして接続が失敗するのかはわからないのです。接続自体が失敗しているので、この先に何もできないという状態です。
ということで、今の段階では、できるだけ接続手段を用意するという意味でも、STARTTLSに対応することが必要だろう。

問題２は、Base64のところが遅いのだと思われる。
このあたりも真剣に調査したわけではないのだが、前回、添付ファイルをつけた時にCRLFではなく、
LFにしてしまっていたあたりを調査した際にもはっきりと遅いな－とは思ったものだ。
ただ、こちらもflex標準のクラスを使っていることから、まあとりあえずは仕方がないなとしてしまった。
しかし、やはりエンコード/デコードは外部に出そうと思う。
まあ、そうすればエンコード・デコード部分だけで調査ができるし、ここを最適化するのもしやすくなるだろう。

しかし、これらの問題が解決しない場合も考えられる。
そこで、JAVA-AIRのブリッジという解決策も用意したいと考えている。
まあ、要するに、airxmailを使って送信しているようでも、実はJavaMailのAPIをたたいているだけという事だ。
そのためにも、airxmailのMimeMessageの構造を見直すことと、エンコード・デコードあたりは外部にださないいけないなという感じです。

airxmailで文字化けしますが・・・・という方いましたので、ちょっと詳しく説明することにしました。
そちらの方はご自分で解決していただけたようですが、確かにわかりにくい気もしますので・・・・
（ご報告していただいた方、ありがとうございました。）

airxmailでは、文字コードは何も設定しないと、JIS(ISO-2022-JP)に設定されます。
ただし、

if(Capabilities.language == "ja"){
   return "ISO-2022-JP";
}
else{
  return "UTF-8";
}

となっており、日本の環境でない（と判断された場合）には、UTF-8になる。
さらに、ただしがあり、文字コードにはairxmailでは２つある。
１つは、ヘッダの文字コードであり、（こちらは日本環境ではなければデフォルトはない。つまり、ASCII)
２つは、本文の文字コードである。

では、この設定を変更するにはどうすればいいかと言えば、

AirxMailConfig.setDefaultBodyCharset("UTF-8");
AirxMailConfig.setDefaultHeaderCharset("UTF-8");

とすることで、何も文字コードを設定していない場合には、UTF-8が使われることになる。

では、個別に文字コードを変えたい場合にはどうすればいいかと言えば、

サブジェクトの場合には

var mimeMsg:MimeMessage = new MimeMessage();
mimeMsg.setSubject("これでUTF-8になるよ","UTF-8");

本文の場合には・・・とこれがちょっとややこしい。
というか、あまりきちんと整理されていないし、こちらで細かくテストをしきれているわけではないので、
問題があるかもしれませんが・・・ので・・それでもやりたい方への一応説明。
（おかしい場所があったら、教えてくださればできるだけ対応します。）

まずは、普通のテキストメールの場合（マルチパートでない場合）には
ContentTypeのcharsetを見ます。

従って、

var mimeMsg:MimeMessage = new MimeMessage(ContentType.parseValue("text/plain; charset=Shift_JIS"));

のようにします。
ただし、これだけでは単なる文字コードがShift_JISになるだけなので、うまくいかないケースもあります。
（このあたりが電子メールの面倒なところです。できるだけ見えるようにするために多少のバグがあっても問題ないケースがあったりするのです。）

ただしくは、

var mimeMsg:MimeMessage = new MimeMessage(ContentType.parseValue("text/plain; charset=Shift_JIS"));
mimeMsg.transferEncoding = "8bit";

にしなければならないのです。
ちなみに、UTF-8にしたときには、自動的にこちらを”8bit”にしてしまいます。
（だったら、SJISとかもすればいいじゃないか・・・かな・・・）

もう一つは、テキストパートの場合です。
こちらは、MimeMessage（ただしくはその親クラスのMimeMultiPart）にcreateTextPart()というメソッドがあります。
こちらの実装が、以下のようになっています。

public function createTextPart(charset:String = null,transferEnc:String = "7bit"):MimeTextPart{
	var part:MimeTextPart = new MimeTextPart();
	if(charset){
		part.contentType.setParameter("charset",charset);
	}
	part.transferEncoding = transferEnc;
	this.addChildPart(part);
	return part;
}

つまり、引数に文字コードを渡してもいいですし、返ってきたオブジェクトのcontentTypeのcharsetにセットしてもいいわけです。
こちらも同様に、設定した文字コードに対応するtransferEncodingを設定する必要があります。

ちなみに、文字化けするが意味がわからない。いったいどこでおかしくなってるんだ。
という方は、リビジョン53で、DirSenderというクラスを追加しました。
こちら、メールを送る代わりに、ローカルのディレクトリにファイルで書き出します。

//var sender:IMailSender = new SMTPSender();
var sender:IMailSender = new DirSender();

と、クラス名だけ変えてもらえば、それで動くようになります。
File.userDirectory.resolvePath(”airxmail”);
のディレクトリに書き出します。