〓〓〓いつまでも次世代 IMAP その２〓〓〓
imap って、同一アカウントで同時にログインしても良いプロトコルですか？
ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
|
|
|
351 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 01:03:31
プロトコルの問題じゃなくて実装の問題だろう。
352 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 01:20:59
>>351の言うとおり、実装の問題
uw-imap使ってたころ、メール消失したことある
uw-imap使ってたころ、メール消失したことある
353 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 02:19:53
Maildir ならOKかも。
354 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 04:04:25
ログインしてメールいじってる時に
SMTPがメールボックスいじると消失とかある？
SMTPがメールボックスいじると消失とかある？
言われてみれば確かに実装の問題ですね・・・。
ストレージ上のメール箱にロックファイルとか
作ってくれる鯖もあるっぽいので、そういうので
排他しようかと思います。
>>354 Maildir ならOKかも。
ストレージ上のメール箱にロックファイルとか
作ってくれる鯖もあるっぽいので、そういうので
排他しようかと思います。
>>354 Maildir ならOKかも。
356 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 09:51:39
357 ：名無しさん＠お腹いっぱい。：2007/09/05(水) 10:37:51
imap はプロトコル的に同時ログイン可。それでぶっこわれるのならば実装が悪い。
実際、thunderbird は1クライアントで複数接続する。が、
>ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
>負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
これって同じメールボックスにアクセスする imap サーバが複数あるということ？
さすがにそれは保証できんだろ。外からは同じに見えても内部的には別なんだから、
それはクライアントとサーバの間の問題ではなく、複数のサーバがひとつの
メールボックスを同時アクセスするときの制御の問題になる。
別ホストで動いているプロセス間で情報をやりとりする仕組みを備えている
実装でないかぎり（そんな実装があるのかどうか知らん）、
同時ログインしたらぶっこわれる可能性が高い。
>Maildir ならOKかも。
maildir が保証するのはあくまでメールの中身だけ。それ以外の管理情報は
別のところに置く実装が多いので、メールと管理情報の不整合が起きる可能性がある。
たとえば、ファイルの実体がサーバ上に残っていても、もし imap サーバがそれを
認識できなくなったとしたら、ユーザからすればメールが消えたのと同じ。
実際、thunderbird は1クライアントで複数接続する。が、
>ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
>負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
これって同じメールボックスにアクセスする imap サーバが複数あるということ？
さすがにそれは保証できんだろ。外からは同じに見えても内部的には別なんだから、
それはクライアントとサーバの間の問題ではなく、複数のサーバがひとつの
メールボックスを同時アクセスするときの制御の問題になる。
別ホストで動いているプロセス間で情報をやりとりする仕組みを備えている
実装でないかぎり（そんな実装があるのかどうか知らん）、
同時ログインしたらぶっこわれる可能性が高い。
>Maildir ならOKかも。
maildir が保証するのはあくまでメールの中身だけ。それ以外の管理情報は
別のところに置く実装が多いので、メールと管理情報の不整合が起きる可能性がある。
たとえば、ファイルの実体がサーバ上に残っていても、もし imap サーバがそれを
認識できなくなったとしたら、ユーザからすればメールが消えたのと同じ。
>imap はプロトコル的に同時ログイン可。
お、そうなんですか。情報ありがとうございます。
>これって同じメールボックスにアクセスする imap サーバが複数あるということ？
はい。ご指摘の通り、異なるホスト間でセッション情報を共有するような
ソフトは恐らくないかと思いますｗ ただ、RDBMS にセッション情報を
置くとか、ファイルシステム上にロック情報を置くとかして代替する
ことは出来るかなぁと思ってます。前者は SQL でフラグを参照するように
出来ればいけそうですし、後者は実装済みのものがありそうです。
# どっちもデッドロック発生の可能性を秘めていますが・・・ｗ
お、そうなんですか。情報ありがとうございます。
>これって同じメールボックスにアクセスする imap サーバが複数あるということ？
はい。ご指摘の通り、異なるホスト間でセッション情報を共有するような
ソフトは恐らくないかと思いますｗ ただ、RDBMS にセッション情報を
置くとか、ファイルシステム上にロック情報を置くとかして代替する
ことは出来るかなぁと思ってます。前者は SQL でフラグを参照するように
出来ればいけそうですし、後者は実装済みのものがありそうです。
# どっちもデッドロック発生の可能性を秘めていますが・・・ｗ
359 ：名無しさん＠お腹いっぱい。：2007/09/06(木) 01:57:01
360 ：名無しさん＠お腹いっぱい。：2007/09/10(月) 00:55:55
10個のアカウントに一気に接続しようとして、全部ちゃんと接続できることが
ほとんどない。こんなものなのかな？
IMAPがこんなものなのか、サーバーがしょぼいのか、メールクライアント
（Becky）が負荷高いのか。。
ほとんどない。こんなものなのかな？
IMAPがこんなものなのか、サーバーがしょぼいのか、メールクライアント
（Becky）が負荷高いのか。。
361 ：名無しさん＠お腹いっぱい。：2007/09/10(月) 06:21:07
エスパーの俺が答えるが、それはテスト方法が間違っている。
362 ：名無しさん＠お腹いっぱい。：2007/09/10(月) 07:11:35
>>358
ただし同時アクセス時の"Message State"についてはRFC 4551でやっと規定されたので、そこら辺のインターオペラビリティは芳しくない。
ただし同時アクセス時の"Message State"についてはRFC 4551でやっと規定されたので、そこら辺のインターオペラビリティは芳しくない。
363 ：名無しさん＠お腹いっぱい。：2007/09/10(月) 09:23:04
RFC4551 は同時アクセス時の Messsage State を規定してるんじゃなくて、
同期を簡単に確実に早くする方法を定めている。
IMAP的には、複数クライアントの同時アクセスは保証していない。
2本目が来たときに、2本目を拒否するか、1本目を切断するサーバもある。
同期を簡単に確実に早くする方法を定めている。
IMAP的には、複数クライアントの同時アクセスは保証していない。
2本目が来たときに、2本目を拒否するか、1本目を切断するサーバもある。