Archive for 8月, 2010
2010/8/6
そこそこバグ修正やら問題対応やら、追加機能を行い、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なら可能です。
Posted in 
2010/8/3
前回、課題をのせましたが、もうちょっと詳細に問題が見えてきました。
１）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としてアップできればと思います。
