At 06:40 PM 3/14/01 +0700, you wrote:
>> semua yg saya tandai itu (kata2 "while awaiting") artinya "selagi menunggu
>> (yg berikutnya datang)" alias "delay".
>
>Betul, tapi delay yang dimaksud adalah antara 2 commands (ini yang
>saya dan Bung Syafril bilang sebagai session), bukan antara 2
>transfer bytes seperti yang anda bilang dalam mail-mail sebelumnya.
ok, awalnya diskusi masalah timeout ini dari sini:
1.saya bilang: kita bisa membuat mailserver "bengong" dengan
cara mengirim data se banyak2nya via *telnet* dgn cara yg
pernah saya perlihatkan itu, atau dengan bom email
yg dikirim dgn client yg tidak issue SIZE.
2.anda dan bung sh bilang: ngga bisa, karena akan kena timeout
(...nah dari sini berkembang diskusi soal timeout...)
3.saya mendapat gambaran bahwa pengertian timeout anda dan bung sh
itu adalah "time limit" (atau istilah anda itu "hard timeout").
saya bilang: pada waktu saya kirim data setelah command
DATA, timeout tidak akan pernah tercapai jika streaming
datanya lancar, jadi ngga mungkin kena timeout.
>Anyway, saya mulai mengerti dengan apa yang jadi masalah anda. Ini
>berkaitan dengan spec yang harus dipenuhi sesudah client issue DATA.
>Note: dalam fase ini, client akan 'tuli', tidak akan bisa mendengar
>'response' apapun dari server. Jadi tinggal bagaimana server bereaksi
>terhadap kondisi ini. Well, there is nothing we can do, about it,
>sobat :-) Itulah SMTP.
nahhhhh....ini yg saya maxud! :). mestinya di masa depan ada "smtp"
yg lebih "smart" lagi. jadi singkatannya bukan lagi *simple* mail
transfer protocol, tapi *smarter* mail transfer protocol :).
>Bisa saja, Arvel atau pembuat MTA lain menetapkan 'hard' timeout
>limit (misalnya pakai setjmp() dan alarm(), tapi ini memberi
>kemungkinan bahwa legitimate mail(s) akan gagal dikirim hanya karena
>melalui batas waktu. Too bad, SMTP, berikut dengan segala
>kelemahannya, didesign untuk melakukan transfer mail dengan baik dan
>reliabel.
saya kira kalau ESMTP SIZE *wajib* di issue oleh setiap mta maka kemungkinan
mta menerima bom email (atau "bom data",kalau dilakukan via telnet) bisa
diperkecil. masalahnya ESMTP SIZE ini di rfc cuman option saja, atau
mungkin "terpaksa dibuat option" demi menjaga kompatibilitas dgn mta jaman
batu.
>Note: meskipun pada fase sesudah DATA, yang ditunggu adalah 'chunk of
>data'. Ini adalah data yang tersimpan di dalam buffer, sampai buffer
>tersebut itu penuh atau client sengaja menjalankan flush(), atau anda
>tekan tombol enter keyboard anda :-)
apakah yg anda maksud itu data baru ditransmisikan setelah
buffer penuh/command flush()/tekan enter? kalau itu yg dimaksud, saya
tidak sependapat. soalnya dengan simulasi telnet itu jelas begitu
saya ketik 1 karakter di telnet client, data langsung dikirim
dan di mta langsung diterima, tanpa harus issue flush() ataupun ketik enter.
atau bukan itu maksudnya?
btw, kalau saya lihat di monitor mdaemon, flush() ini
kelihatannya inisiatif mdaemon, bukan inisiatif client.
betul ngga bung sh? cmiiw
-DM-
--
--MDaemon-L----------------------------------------------------------
Milis ini untuk Diskusi antar pengguna MDaemon Mail Server.
Untuk menghubungi moderator/List Owner double click link dibawah ini:
<mailto:[EMAIL PROTECTED]>
Untuk Unsubscribe, double click link dibawah ini langsung kirim
<mailto:[EMAIL PROTECTED]>
Untuk Subscribe, double click link dibawah ini langsung kirim
<mailto:[EMAIL PROTECTED]>
--POWERED BY MDAEMON!------------------------------------------------
