On 2003.10.23_10:32:42_+0000, adi wrote: > katakanlah exim (note: perilaku ini configurable), dia tinggal > membuat hint database, kalau proses X sedang mengirim ke hotmail.com. > semua mail ke hotmail akan dihandle oleh proses X. mulai dari scanning > queue dir, sampai resolve dns dilakukan dalam satu korpus program. > jadi lebih mudah dibanding MTA yang modular, di mana scheduler > merupakan program terpisah dengan smtp client yang benar-benar > melakukan remote deliveries. perlu diingat ini adalah keputusan > designer (developer) MTA ybs. kalau sekedar implementasi sih > saya percaya pasti bisa. saya yakin pernyataan berikut tidak > 100% tepat, tapi boleh dibilang: mta monolitik sebenarnya tidak > punya (tidak perlu) scheduler.
saya menggunakan qmail untuk contoh modular MTA. jika qmail mengimplementasikan ini ke dalam katakanlah qmail-remote, dan setiap percobaan ke secondary MX dilakukan dengan proses yang sama, bukankah problem ini sama dengan problem pada monolithic MTA? memang scheduler masih diperlukan. tapi begitu scheduler memutuskan bahwa sebuah entri dalam queue akan dideliver secara remot, ini akan dilakukan terhadap semua MX servers berdasarkan urutan prioritasnya. dengan cara ini, problem mail routing dapat disolve sama seperti pada monolithic MTA. kalau begitu, please point me again, di mana letak perbedaan implementasi ini dalam modular MTA? are we going to start a new thread for this? :) > bisa dibuat strict no problemo. Dan, sepertinya DS mengacaukan > antara pengertian mailserver backup dengan secondary MX. ingat > secondary MX bisa saja merupakan autoritative mailserver untuk > domain ybs! (bayangkan mail farm, red). dalam sebuah farm, jika load balancing diaplikasikan, maka setiap server bertindak sebagai primary. jika farm yang dimaksud hanyalah kumpulan dari server yang independen, maka hanya ada satu mailserver yang berfungsi sebagai main server. selebihnya, berfungsi sebagai backup, hanya jika main server down, alias secondary MX. tentu saja, untuk men-queue email jika main server down, secondary MX harus authoritative untuk domain ybs, kalau tidak, mail akan direject. > > reliablity, security. > . > > simplicity, reliability. > > janganlah jadikan itu sebagai menara gading ... kalau spec jelas, > sudah dari dulu-dulu ditulis oleh mereka (bapak-bapak pembuat > MTA). reliability, security, simplicity yang anda sebutkan itu > tetap bisa berlaku walaupun nanti exim, qmail dan postfix jadi > support DSN. karena reliability, security, simplicity itu melulu > soal MOTTO, sedang MTA adalah program yang harus ditulis, lebih > ke implementasi praktis/real, yang perlu keringat, biaya dll. > untuk hint saja, sorry kalau bombastis, kalau mau membuat > mta yang benar-benar reliabel, simpel dan secure caranya gampang: > jangan membuat MTA :-) DSN sendiri terlalu complex untuk diimplementasikan. daripada mengaplikasikan sesuatu dengan membabi-buta, maka qmail memilih tidak, dan tetap mempertahankan mottonya. saya dapat melihat hubungan antara motto itu dengan opini Anda. > sesekali DJB menyebut soal zeroseek. walaupun 'vapourware' tapi > kalau ini benar diimplementasikan di qmail, barulah orang bisa > membandingkan kecepatan (tanpa mengesampingkan reliabilitas) > antara qmail vs postfix. kenyataan yang ada sekarang qmail K.O. ini tidak membuat qmail mempunyai bug. selebihnya, nilai setiap benchmark dengan jeli. > > lagipula, tidak ada yang menggunakan istilah synchronous write di > > "linux". > > gini saja kalau gitu .. anda jelaskan maksud dari 'synchronous write', > sekaligus mencamkan di pikiran anda bahwa ini milis linux-admin. > bisa jadi kita pakai 'jargon' yang berbeda dan saya salah mengerti > dengan yang anda tulis. maksud Anda, di dalam milis linux-admin, setiap hal yang disebutkan tanpa embel-embel, dapat diasumsikan linux? saya tidak setuju, dan itulah yang saya protes. we're using the same jargon. saya menggunakan istilah itu untuk umum, di mana sebuah proses write akan dilakukan secara sinkron untuk menjamin konsistensi dari filesystem. > just another positivism :-) Saya kurang tertarik dengan motivasi > (bahkan saya tidak tertarik dengan kesimpulan pembuat benchmark), > saya hanya tertarik pada data dan hasil. kesimpulan bisa didiskusikan. dari data dan hasil yang menyimpang, ditariklah kesimpulan yang salah. Anda tidak tau motivasi pembuat benchmark, Anda bisa saja melahap semua datanya mentah-mentah. tanpa mengetahui motivasi, pembunuhan tanpa sengaja dan terencana hanya akan menunjukkan hasil yang sama: seorang telah meninggal. desain MTA beda, susah sekali menemukan cara yang fair untuk membuat benchmark yang dapat diandalkan. saya bahkan tidak tertarik dengan perbedaan beberapa detik yang ditunjukkan oleh benchmark. saya hanya tertarik pada cara sebuah MTA memecahkan dan memberikan solusi atas masalah saya. > upss sorry, kurang nol he..he.. > > 1000 per menit = 60 * 24 = 1440000 ~ 1500000 ok. > > that's the point. ketika kebutuhan bertambah, single system dapat > > memenuhi kebutuhan, and more. patch ini diperlukan kalau kebutuhan > > tinggi, tapi menggunakan satu sistem. > > itu meminimalkan risiko. anda akan paham kalau anda bekerja > untuk ISP. 1000 per menit itu kira-kira 16 msgs/s. kemungkinan sekali lagi Anda mengasumsi tentang latar belakang saya. > besar bottleneck adalah disk dan bandwidth. Tapi gini, point > saya: jangan mulai dulu dengan patch! lakukan dengan apa adanya, > kalau kurang baru dipatch. berapa load MTA anda sehari? anda > pakai patch ini? jangan salah paham, saya juga akan mengambil pendekatan seperti Anda. tapi pernyataan bahwa patch ini useless, tidak valid. arsip mailing list qmail membuktikan untuk Anda. > > btw, apa yang Anda maksud dengan "red"? setau saya sih komentar > > redaksi.. > > benar :-) Anda sepertinya tidak mengerti fungsi dari "red." -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
