Kisah e-mail, yang tidak lebih dari 500 mil dari pengirim , telah lama menjadi klasik berjanggut. Saya pikir reaksi normal hanya dengan tertawa, tetapi tidak sedikit orang yang ingin membuktikan kepada penulis bahwa ini tidak mungkin, karena ... Pada akhirnya, penulis tidak tahan dan mengeluarkan seluruh FAQ. Jadi temui:Email yang tidak lebih dari 500 mil
Saya telah menerima banyak tanggapan untuk publikasi, "Mail tidak melampaui 500 mil." Kisah saya dicetak ulang berkali-kali dan dijual jauh lebih luas dari yang saya harapkan. Sebagian besar jawabannya adalah terima kasih untuk cerita lucu dan tawaran pekerjaan (omong-omong, terima kasih untuk mereka, dan saya ingin mereka terus datang!) Namun, ada banyak yang mencari ketidakakuratan dan kontradiksi dalam cerita saya, menemukan kesalahan dengan hal-hal sepele. Alih-alih menjawab setiap serangan seperti itu, saya hanya mengumpulkan pertanyaan yang paling sering diajukan dan menjawab sekaligus.
1. Apakah itu benar, atau apakah sejarah hanyalah sebuah cerita?Itu adalah kenyataan. Pada saat itu, saya bertanggung jawab untuk sistem email terpusat di kampus University of North Carolina di Chapel Hill. Selain itu, saya juga terlibat dalam mengatur e-mail untuk departemen-departemen yang karena alasan tertentu menggunakan server mereka sendiri. Hal utama dalam konteks cerita ini adalah saya menulis file konfigurasi untuk server mail, sendmail.cf, yang digunakan oleh sebagian besar server kampus.
2. Kapan cerita ini terjadi?Saya benar-benar ingin mengatakannya dengan pasti. Namun terlepas dari kenyataan bahwa saya adalah salah satu dari mereka
(dalam aslinya - saya adalah salah satu dari tipe anal-retensive) yang dengan hati-hati menyimpan semua surat mereka, masuk dan keluar, saya tidak dapat menemukan satu surat pun tentang masalah ini. Ketika saya menulis, saya diberitahu tentang masalah itu melalui telepon, dan saya juga menjawab melalui telepon. Setelah beberapa waktu, saya secara sadar memutuskan untuk tidak menulis surat apa pun, terutama karena ceritanya sangat bagus, dan saya suka menceritakannya kembali dan menonton wajah orang-orang yang mendengarnya untuk pertama kalinya. Berdasarkan ingatan kantor tempat saya bekerja saat itu, dari kolega-kolega tempat saya menceritakan kisah ini, dan perincian lain yang tidak relevan tetapi berkaitan dengan waktu, kisah itu terjadi sekitar tahun 1994-1997.
Namun, Anda tentu dapat menghitung waktu dengan lebih akurat. Misalnya, ketika sendmail 8 sudah "cukup stabil", tetapi apakah Sun masih mengirim sendmail 5? Eric Allman (Eric Allman) menulis kepada saya tentang hal ini, bahwa beberapa fungsi dapat di-backport ke sendmail 5, dan jika Anda tahu kapan itu, Anda dapat secara signifikan mempersempit interval waktu. Secara umum, jika Anda memiliki pemikiran tentang bagaimana menghitung waktu sebuah cerita dengan lebih akurat, saya akan mendengarkannya dengan rasa terima kasih.
3. Apakah cerita ini benar-benar terjadi pada Anda, atau kepribadian tokoh utama dari "detail yang tidak relevan" yang diubah?Ini benar-benar kisah saya. Mungkin salah satu kolega saya memperingatkan saya bahwa "sesuatu terjadi di kantor statistik," sebelum berbicara dengan kepala departemen. Bahkan mungkin saya memanggil kepala departemen, dan bukan dia. Kemungkinan besar, salah satu kolega saya duduk di sebelah saya ketika saya sedang menyelesaikan masalah, karena saya memiliki kebiasaan membahas masalah kerja dengan keras dalam proses penyelesaian. Tapi saya jarang menceritakan kisah orang lain dan menuai kemenangan orang lain. Meskipun, jika Anda bekerja dengan saya pada waktu itu dan Anda berpikir bahwa menyelesaikan masalah adalah jasa Anda, hubungi saya dan kami akan menemukan sesuatu.
4. Jika Anda tidak 100% yakin akan detailnya, lalu mengapa ada begitu banyak detail dalam cerita?Karena dengan detailnya, ceritanya terlihat jauh lebih baik. Apakah Anda benar-benar berpikir bahwa jika saya memulai setiap kalimat dengan kata-kata "Saya tidak ingat persis, tetapi sepertinya ...", maka sesuatu akan berubah? Pada akhirnya, di awal, saya memperingatkan bahwa beberapa detail kecil telah diubah, dan beberapa sengaja dihilangkan - hanya untuk membuat cerita lebih baik.
Poin penting kedua adalah situs tempat cerita pertama kali diterbitkan. Saya mengirim cerita ini ke milis SAGE (System Administrators Guild) di bagian "tantangan luar biasa". Ini hanya cerita tentang tugas paling luar biasa yang kadang-kadang diberikan manajemen kepada administrator sistem.
Tentu saja, jika saya tahu bahwa cerita itu akan menyebar ke seluruh Internet, saya akan lebih berhati-hati dalam menulis. Tetapi teks itu ditulis untuk kolega, yang kebanyakan saya kenal secara pribadi, dan yang, pada umumnya, cenderung mempercayai saya.
5. Ceritanya lucu, tetapi rincian teknis pada akhirnya salah.Ya saya tahu. Baca kembali jawaban untuk pertanyaan sebelumnya. Pertama-tama, saya menulis cerita lucu berdasarkan insiden yang terjadi pada saya. Ini bukan materi pendidikan, jadi tidak ada rincian teknis lebih dari yang diperlukan untuk memahami makna umum dari apa yang terjadi. Secara umum, setelah menulis cerita ini, saya dijiwai dengan rasa hormat yang besar kepada penulis yang menulis cerita berdasarkan peristiwa nyata.Sekarang saya tahu betapa sulitnya menjaga keseimbangan antara kredibilitas dan fiksi. Dan sekarang saya tahu betul betapa banyak kritik yang menghantui penulis, memilih suku kata seni :-)
6. Baiklah, baik, tetapi mengapa Anda tidak menulis materi pelatihan sekarang?Sayangnya, ini tidak akan berfungsi, bahkan jika saya mau, karena saya tidak memiliki sumber data. Saya tidak menyimpan log, dan saya tidak punya catatan yang kemudian saya buat. Saya benar-benar ingin mereka dilestarikan, karena saya mengerti bahwa saya bisa membuat artikel yang bagus dari mereka. Kemudian semua ini tampak sepele, hanya layak dijadikan lelucon bagi sekelompok kecil teman. Dan saya mengatasi tugas ini - bahkan tanpa catatan dan catatan.
Meskipun ... sebenarnya ada detail yang saya ingat atau bisa kembalikan. Dan saya menggunakannya untuk menjawab pertanyaan-pertanyaan berikut.
7. Mengatur batas waktu connect () menjadi 3 ms tidak masuk akal.Ya saya tahu. Tetapi tidak ada instalasi seperti itu. Cerita ini menjelaskan bagaimana saya menghabiskan 10 menit bergerak dari batas 500 mil pada kisaran pengiriman email ke batas waktu 3 ms, karena kecepatan cahaya. Bahkan, prosesnya memakan waktu beberapa jam, dan pekerjaan saya dapat dibandingkan dengan pekerjaan seorang detektif. Pada akhirnya, saya menemukan solusinya, menjalankan tes dan menuangkan kopi (apalagi, saya yakin ini jauh dari cangkir kopi pertama). Jadi sama saja, apa yang sebenarnya membingungkan Anda dalam angka "3 ms"?
8. Yah, pertama, 3 ms jelas tidak cukup, karena ini hanya cukup untuk paket keluar untuk mencapai penerima. Tetapi Anda masih perlu mendapatkan jawaban, jadi penundaan minimum harus 6 ms?Tentu saja Ini hanyalah salah satu detail yang saya abaikan. Terlalu rumit dan membosankan untuk sebuah cerita lucu.
9. Atau mungkin batas waktu biasanya 12/18/24 ms karena protokol koneksi TCP tiga fase?Mungkin Sekali lagi, ini adalah detail yang tidak dapat saya ingat karena saya kehilangan semua catatan. Namun, saya berpikir bahwa ketika paket SYN / ACK diterima, batas waktu fungsi connect () direset, yaitu, tidak perlu bahwa koneksi TCP harus sepenuhnya dibangun selama batas waktu. Ya, bahkan jika itu harus, bagaimanapun, menceritakan kisah itu, saya akan mengurangi semua perhitungan yang rumit ini ke angka "3".
10. Peralatan jaringan menyebabkan penundaan aliran sinyal yang jauh lebih besar daripada yang Anda duga.Ya, Anda mungkin benar. Tapi saya bisa memperhitungkan penundaan ini. Saya tidak yakin bahwa saya melakukan semuanya seperti itu, tetapi saya bisa, misalnya, melakukan ping ke router terdekat (misalnya, router yang melayani jaringan perguruan tinggi lain di universitas kami) untuk menghitung berapa lama penundaan yang diberikan router. Lalu saya bisa melipatgandakan penundaan yang dihasilkan oleh jumlah node yang dilalui sinyal melewati ke tujuan. Jumlah ini kira-kira sama untuk semua universitas di Pantai Timur. Tetapi bahkan jika ini tidak demikian, penundaan yang ditambahkan oleh satu router redundan adalah beberapa ratus mikrodetik, yang tidak terlalu mempengaruhi waktu keseluruhan.
11. Sebuah cerita lucu, tetapi ada cacat fatal di dalamnya : sinyal di kawat tembaga tidak merambat dengan kecepatan cahaya.Ya, itu adalah, sinyal datang pada kecepatan ¾c atau lebih. Tetapi jaringan kampus, dan tulang punggungnya, seluruhnya serat optik.
12. Aha! Tetapi bahkan dalam serat optik, cahaya tidak merambat dengan kecepatan yang sama seperti di ruang hampa udara!Ya, ini dia. Dalam serat optik, sinyal bergerak dengan kecepatan dari ⅔c (ya, lebih lambat dari pada kabel tembaga) ke hampir c, tergantung pada banyak faktor. Tapi saya ulangi sekali lagi - semua ini bisa saya perhitungkan dan, tentu saja, perhitungkan. Saya melakukan ping node yang berbeda dan mencatat waktu ping dan jarak ke node. Membandingkan angka yang diperoleh, saya menyimpulkan "waktu empiris" tertentu, yang sedikit berbeda dari waktu nyata. Namun, semua ini juga detail yang tidak penting, yang saya abaikan untuk membuat cerita lebih pendek dan lebih menarik.
13. Stop-stop-stop ... Apakah Anda ingin mengatakan bahwa Anda pertama kali menebak bahwa masalahnya entah bagaimana terkait dengan kecepatan cahaya, dan baru kemudian pergi ke perhitungan (dalam aslinya - "mengetikkannya ke dalam unit", yaitu, menggunakan utilitas unit) ?Ya persis. Saya keras kepala. Sudahkah Anda, selama proses pemecahan misteri, tidak memperhatikan jawaban yang benar? Inilah yang terjadi pada saya. Kemungkinan besar, sebaliknya, saya pertama kali mentransfer 500 mil ke milidetik ringan dan baru setelah itu saya menyesuaikan jawaban untuk pengetahuan ini.
14. Yaitu, Anda tahu cara memecahkan masalah pengguna, tetapi tidak menyelesaikannya sampai Anda tahu bahwa itu adalah batas waktu?Tidak. Segera setelah saya menyadari bahwa mengganti sendmail standar di SunOS dengan sendmail 8 menyelesaikan masalah, saya melakukannya. (Bahkan jika saya tidak tahu bahwa ini akan menyelesaikan masalah, saya akan melakukannya karena sendmail 5 dengan parameter dari sendmail 8 bukan konfigurasi terbaik). Tapi saya menyimpan biner lama - untuk tetap menangani masalah di waktu luang saya.
Administrator sistem selalu melakukan ini. Tidak pernah terjadi bahwa "sistem telah berjalan dan lelah terlalu lama," tetapi mem-boot ulang sering kali membantu. Pertama, administrator memecahkan masalah sebaik mungkin sehingga pengguna dapat terus bekerja, dan kemudian kembali dan mencari penyebab sebenarnya dari apa yang terjadi.
15. Biasanya, data bergerak melalui Internet dengan rute yang sangat aneh, tetapi dalam cerita ini pengirim selalu terhubung langsung ke penerima. Bagaimana bisa begitu?Tidak mungkin. 500 mil plus atau minus - ada zona untuk mengirim surat di luar yang tidak mungkin. Di dalam zona ini ada juga simpul di mana surat tidak dikirim atau dikirim dengan keberhasilan yang berbeda-beda.
Setidaknya ada dua alasan untuk ini. Yang pertama adalah beberapa penundaan tambahan (misalnya, pada firewall), yang menyebabkan berakhirnya batas waktu. Yang kedua - jalur menuju simpul-simpul ini sangat sulit, dan panjang totalnya lebih dari 500 mil.
Jaringan University of North Carolina dibangun dengan sangat baik, dan jalur sinyal ke universitas lain di Pantai Timur (di mana, pada kenyataannya, pengiriman surat berhasil) hampir langsung
(dalam aslinya, ortodromi) , terutama ketika cerita ini terjadi. Pada masa itu, paket dari Atlanta ke Washington jarang melewati San Jose.
16. Dan mengapa Anda masih perlu menyebutkan dalam sejarah bahwa jaringan Anda hampir sepenuhnya dibangun di atas sakelar?Saya tidak tahu. Pada saat itu, tampaknya tanpa komentar ini, cerita itu akan sepenuhnya tidak masuk akal. Meski sekarang saya tidak mengerti kenapa. Jadi, ketika Anda membaca kembali ceritanya, Anda dapat secara mental membuang paragraf yang sesuai.
Seorang pengguna dengan julukan Hacksaw menulis yang berikut ini: “Berpindah tidak termasuk penundaan, misalnya, untuk menyelesaikan tabrakan. Tidak adanya penundaan seperti itu menyederhanakan pencarian untuk masalah yang dijelaskan, karena data untuk analisis lebih bersih. Aku yakin kamu bersungguh-sungguh. ”
17. Sendmail 5 tidak mengerti file konfigurasi dari sendmail 8.Tapi dia mengerti. Saya telah diberitahu bahwa sendmail 5 yang dapat ditemukan di jaringan tidak mengerti. Karena itu, saya terpaksa berasumsi bahwa hanya sendmail, yang disediakan oleh Sun sebagai bagian dari Solaris, yang dapat melakukan ini. Jika Anda memiliki akses ke sumbernya, saya akan berterima kasih untuk memeriksa apakah ini mungkin. Tapi tetap - itu terjadi, yang berarti itu bisa terjadi :-)
18. sendmail memiliki nilai parameter default yang digunakan untuk mengompilasinya; itu tidak bisa hanya mengatur semua parameter yang tidak diinisialisasi ke 0.Beberapa orang menulis kepada saya tentang ini. Hari ini, mungkin memang demikian, tetapi pada masa itu jelas tidak demikian. Saya yakin akan hal ini, karena satu atau dua tahun setelah cerita ini terjadi, saya berada di sebuah lokakarya sendmail di LISA bersama Eric Allman. Dia memperhatikan bahwa sendmail tidak memiliki nilai default untuk beberapa opsi yang dia bicarakan (dalam sendmail standar. Jika nilai-nilai ini, tetapi, seperti yang Anda ingat, ini tidak berlaku untuk riwayat kami). Saya mengambil kesempatan itu dan menceritakan sebuah kisah sekitar 500 mil. Dia benar-benar berbaring di bawah meja dengan tawa :-)
19. Utilitas unit di SunOS tidak memahami unit seperti "milidetik cahaya" (dalam terjemahan Rusia dikatakan "ambil 3 milidetik dan kalikan dengan kecepatan cahaya", dan output utilitas unit ditampilkan dalam aslinya)Ya Jadi apa Pada semua mesin tempat saya bekerja, saya menulis unit saya sendiri. Dengan banyak unit tambahan dan awalan. Dan secara umum, sejauh yang saya ingat, unit saya mulai di bawah AIX. Saya tidak tahu apakah saya tahu tentang milidetik cahaya AIX. Periksa unit. Dat yang datang dengan distribusi Linux apa pun hari ini. Dia mungkin tahu tentang milidetik cahaya (mililighteconds).
20. Tentu saja, sangat mudah untuk merujuk ke "catatan hilang" ...Tentu saja Dan berapa banyak kertas yang Anda simpan lima tahun yang lalu?
21. Bagaimanapun, cerita ini adalah fiksi!Jawab pertanyaan: jika kita mengabaikan detail teknis, dapatkah konfigurasi server mail yang salah menyebabkan fakta bahwa surat-surat dikirim ke penerima di dekatnya, tetapi tidak ke penerima jarak jauh? Saya pikir jawabannya adalah ya. Sebenarnya, saya tahu jawabannya adalah ya karena itu benar-benar terjadi. Tetapi bahkan jika Anda tidak mempertimbangkan pengalaman saya dan melihat pertanyaan dari luar, saya pikir itu masih mungkin, meskipun pada pandangan pertama tampaknya tidak masuk akal.
Jika Anda masih memiliki pertanyaan yang belum saya jawab, kirimi saya email di trey+500mi@lopsa.org. Saya akan menambahkan pertanyaan Anda ke FAQ dan menyebut Anda sebagai penulis. Tetapi kemungkinan besar, saya hanya akan mengatakan, "Saya tidak tahu, saya tidak ingat, dan saya tidak punya data untuk dijawab."
22. Tanda tangan mengatakan bahwa Anda mencari pekerjaan. Apakah ini masih relevan? (tanda tangan dihapus dalam terjemahan Rusia)Tidak lagi, tapi terima kasih atas pertanyaan ini!