Fungsi dijamin tidak akan pernah mengembalikan nilai yang sama dua kali [ditutup]


23

Ini adalah pertanyaan yang saya tanyakan pada wawancara kerja, dan saya tidak dapat menemukan jawaban yang mereka cari, jadi saya berharap seseorang di sini mungkin memiliki beberapa ide. Tujuannya adalah untuk menulis fungsi yang dijamin tidak akan pernah mengembalikan nilai yang sama dua kali. Asumsikan bahwa fungsi ini akan diakses oleh beberapa mesin secara bersamaan.

Ide saya adalah untuk memberikan setiap mesin id unik dan meneruskan nilai itu ke fungsi pembuat nilai unik:

var i = 0;
function uniq(process_id, machine_id) {
   return (i += 1).toString() + machine_id + "-" + process_id;
}

Ini akan menghindari kejatuhan dari kondisi balapan karena bahkan jika dua proses atau lebih membaca nilai yang sama i, setiap nilai kembali ditandai kombinasi unik id proses dan id mesin. Namun, pewawancara saya tidak suka jawaban ini karena membawa mesin lain secara online melibatkan menetapkannya sebagai id.

Jadi adakah yang bisa memikirkan cara lain untuk menyelesaikan ini yang tidak melibatkan mengkonfigurasi setiap mesin untuk memiliki id yang unik? Saya ingin mendapat jawaban kalau-kalau pertanyaan ini muncul lagi. Terima kasih.


31
Dijamin dalam arti kata yang ketat? Maksudku, bahkan Guids pada suatu titik akan mulai mengulangi sendiri Kita mungkin tidak hidup lagi, tapi menjamin .. Dan omong-omong, ID proses masih jauh dari unik .
JensG

7
@CodesInChaos - Itu adalah asumsi yang cukup buruk, mengingat bahwa itu sepele dalam beberapa sistem operasi untuk mengubah alamat mac Anda.
Telastyn

7
"Asumsikan bahwa fungsi ini akan diakses oleh beberapa mesin secara bersamaan" - jujur, ini bisa berarti "kode berjalan pada setiap mesin secara individu, tanpa komunikasi antar mesin", atau "ada mesin pusat / pusat basis data tempat fungsinya disediakan untuk mesin lain, tersedia melalui jaringan ". Anda harus mulai mengklarifikasi ini terlebih dahulu.
Doc Brown

28
Apakah itu pertanyaan jebakan? Sebagai contoh, sebuah fungsi yang mengandung infinite loop tidak akan pernah mengembalikan nilai yang sama dua kali ..
Brendan

8
Mungkin mereka mencari seorang programmer yang mengajukan pertanyaan tentang persyaratan yang meragukan, daripada membuat asumsi dan menjalankannya :)
theMayer

Jawaban:


60

Jangan suka, cukup lempar penghitung sederhana (threadsafe) di balik titik akhir komunikasi (WCF, layanan web, apa pun):

   long x = long.MinValue;
   public long ID(){
       return Interlocked.Increment(ref x);
   }

Ya, pada akhirnya akan meluap. Ya, itu tidak menangani reboot. Ya, itu tidak acak. Ya, seseorang dapat menjalankan ini di beberapa server.

Ini adalah hal paling sederhana yang memenuhi persyaratan praktis. Lalu biarkan mereka menjadi orang-orang yang menindaklanjuti masalah-masalah itu (untuk memastikan mereka memahami keterbatasan, apakah mereka benar - benar berpikir Anda membutuhkan lebih dari 2 ^ 64 id), sehingga Anda kemudian dapat bertanya tentang trade-off apa yang baik-baik saja. Apakah itu perlu selamat dari reboot? Bagaimana dengan kegagalan hard drive? Bagaimana dengan perang nuklir? Apakah perlu acak? Seberapa acak?


7
Ini adalah jawaban yang baik, karena pewawancara tidak pernah mengajukan pertanyaan untuk mendapatkan jawaban langsung. Mereka ingin Anda memberikan jawaban di mana Anda dapat membenarkan keputusan Anda. Jika Anda memahami domain, hampir semua jawaban akan cocok jika Anda dapat membenarkannya.

7
Bagaimana ini bisa berfungsi jika kode berjalan pada mesin yang berbeda (jadi jelas dalam proses yang berbeda)? Setiap proses akan memiliki salinan yang berbeda x. Dan saya pikir tanpa penjelasan tentang jenis mekanisme interlocking yang ada dalam pikiran Anda, jawaban ini cukup kabur.
Doc Brown

7
@DocBrown "diakses oleh beberapa Mesin secara bersamaan" tampaknya menyiratkan bahwa beberapa mesin mengakses fungsi tunggal pada satu server. Kalau tidak harus dituliskan "Beberapa mesin akan menjalankan salinan dari fungsi ini pada saat yang sama"
Falco

3
@LightnessRacesinOrbit: Saya kira ini dimaksudkan untuk C #, dan System.Threading.Interlockedkelas, yang menyediakan peningkatan atom. Tetapi Anda dapat juga membaca ini sebagai semacam kode semu.
Doc Brown

3
Jika saya orang yang bertanya, saya akan sangat tidak senang dengan proposal ini. Mulai menerapkan sesuatu tanpa mengetahui apa persyaratannya adalah bendera merah besar. Saya mengharapkan Anda untuk bertanya.
JensG

25

Jika saya ditanya pertanyaan itu, dan mereka menjelaskan bahwa itu harus unik di reboot dan di mesin yang berbeda, saya akan memberi mereka fungsi yang memanggil mekanisme standar untuk membuat GUID baru, apa pun yang terjadi di bahasa yang digunakan.


Masalah dengan GUID v4 adalah bahwa mereka hanya sangat unik, tidak dijamin unik. Bukan masalah besar dalam praktik, tetapi tidak memenuhi persyaratan jika pewawancara menganggapnya secara harfiah.
CodesInChaos

Khususnya, jika mekanisme standar GUID tidak memenuhi persyaratan pewawancara, maka goda perbedaan-perbedaan persyaratan antara pewawancara dan pengguna GUID biasa. Seorang pewawancara yang masuk akal menanyakan pertanyaan semacam ini ("bagaimana Anda melakukan <beberapa hal standar yang mungkin diketahui secara umum mungkin dengan sedikit variasi dari persyaratan yang biasa>") harus mengharapkan jenis jawaban yang sangat berbeda dari para kandidat yang mengetahui keadaan terkini untuk GUID dan kandidat yang menciptakan sesuatu dari awal.
Steve Jessop

Ini mungkin jawaban yang paling sederhana, dengan asumsi persyaratan yang fleksibel.
theMayer

9
Memberi +1 karena ini pada dasarnya adalah masalah yang dipecahkan oleh panduan. Memproduksi Panduan duplikat, apa pun formatnya, adalah lotre yang paling sulit di planet ini. Rupanya banyak orang tidak memiliki rasa ketidaksamaan eksponensial tabrakan.
usr

3
Oh, dan jika Anda menawarkan jawaban "gunakan fungsi standar" untuk pertanyaan seperti itu, harapkan pertanyaan lanjutan "dan bagaimana fungsi standar diterapkan?". Yang mungkin Anda jawab dengan sangat baik, "Saya tidak tahu, tapi saya pasti akan mencarinya daripada mencoba menciptakan sesuatu", yang merupakan jawaban yang sepenuhnya akurat yang benar-benar gagal mempertahankan penangguhan ketidakpercayaan yang diharapkan dalam kondisi wawancara, bahwa Anda akan pernah melakukan sesuatu yang penting tanpa melakukan riset terlebih dahulu ;-)
Steve Jessop

22

Pewawancara mengatakan metode ini akan dipanggil bersamaan, bukan paralel; cukup kembalikan tanggal / waktu ke tempat desimal sebanyak yang Anda bisa.

Mengapa semua orang terlalu memikirkan ini? Anda akan mati lama sebelum keterbatasan dikeluarkan dan Anda tidak memiliki peluang tabrakan.

Jika Anda khawatir hal itu mengembalikan waktu yang sama, tambahkan penundaan untuk jumlah waktu terkecil yang dapat diukur.

Jika Anda khawatir tentang mengatur mundur jam untuk waktu musim panas (mengalami 1 kali dua kali), tambahkan konstanta pada waktu kedua kalinya Anda mengalaminya.


12
Atau hanya mengembalikan waktu UTC terlepas dari zona waktu pemohon. Karena UTC tidak dilokalkan maka ia tidak akan terpengaruh oleh perubahan DST.
Mauro

1
System.currentTimeNanos () :-)
Falco

1
Kecuali jika Anda mengembalikan tanggal & waktu dalam format yang dapat dibaca manusia, nilai Anda seharusnya tidak memiliki informasi zona waktu di dalamnya.
Lightness Races with Monica

12
Jumlah waktu terkecil masih akan menghasilkan tabrakan jika disebut cukup / secara bersamaan. Ini juga akan menghasilkan tabrakan karena penyimpangan sinkronisasi jam, manipulasi jam jahat, dan jika Anda tidak hati-hati - penghematan siang hari.
Telastyn

1
Sangat kreatif, setidaknya. Mengandalkan jam yang akan disesuaikan setiap sekarang dan kemudian masih bukan ide yang bagus, IMHO. Offset tidak akan menyelamatkan Anda dari benturan.
JensG

15

Pertama, Anda ingin menanyakan dua pertanyaan kepada pewawancara.


Pertanyaan 1.

apakah pewawancara mengharapkan satu atau lebih "mesin pusat" yang akan digunakan untuk menetapkan beberapa nomor unik, atau blok nomor unik.


Pertanyaan 2.

Apakah pewawancara mengharapkan mekanisme untuk mendeteksi tabrakan, atau sebaliknya menerima risiko yang dihitung dari kemungkinan tabrakan yang sangat kecil tanpa secara eksplisit mendeteksi mereka.

Ada juga pendekatan pertahanan-mendalam, di mana seseorang memasukkan beberapa bagian ID pengguna ke dalam keacakan (dengan demikian, tidak sepenuhnya acak). Karena itu kemungkinan pengguna yang sama mengalami tabrakan di dalam konten yang dibuat oleh pengguna yang sama itu diturunkan.


Ada pertanyaan tersirat 3, ...

Tetapi Anda harus mengukur diri sendiri tanpa bertanya, karena sangat tidak sopan untuk bertanya kepada pewawancara Anda.

Apakah pewawancara mengasumsikan pengetahuan tentang probabilitas, risiko, dan beberapa teknik sederhana yang digunakan dalam sistem kriptografi dan keamanan informasi.

Jenis pengetahuan pertama memastikan Anda tidak berusaha meyakinkan orang yang tidak ilmiah untuk menerima konsep ilmiah yang tidak akan mereka terima.

Jenis pengetahuan kedua memastikan bahwa Anda mengatasi masalah yang selain kemungkinan belaka. Dengan kata lain, cara mempertahankan diri dari "penyerang" yang ingin secara sengaja merusak skema pengacakan Anda, dengan memanipulasi mesin (s) atau host virtual mereka untuk memaksa dua mesin untuk menghasilkan nilai yang sama.


Kenapa bertanya.

Alasannya adalah bahwa jika pewawancara mengharapkannya dengan satu atau lain cara, mencoba menjawab dengan pendekatan yang berlawanan tidak akan pernah membuat pewawancara bahagia.

Alasan yang lebih dalam adalah bahwa beberapa orang tidak menyukai gagasan mengatakan, 1.0e-20peluang untuk gagal. (Saya akan mencoba untuk tidak mengemukakan argumen filosofis atau agama di sini.)


Pertama-tama "namespace" angka acak dibuat menjadi hierarki, dengan jumlah bit tertentu dialokasikan ke satu sumber pengacakan, dan jumlah bit lainnya dialokasikan untuk beberapa cara lain, dll.

Pendekatan terpusat bergantung pada beberapa otoritas pusat untuk secara unik menetapkan bit tingkat pertama. Kemudian, mesin lain dapat mengisi sisa bit.

Ada beberapa pendekatan desentralisasi:

  • Hanya menghasilkan angka acak sebaik yang bisa dilakukan, dan menerima peluang praktis nol untuk gagal dibenarkan oleh perhitungan.
  • Gunakan cara kriptografi menghasilkan nilai acak dari sumber deterministik, katakanlah, nilai yang bertambah.

Saya pikir ini adalah jawaban terbaik. Yang lain adalah solusi tanpa persyaratan.
Jack Aidley

Mengomentari pertanyaan ketiga Anda - tampaknya kompetensi adalah asumsi yang aman, atau setidaknya yang tidak relevan. Jika perusahaan tidak menyediakan pewawancara yang kompeten, kemungkinan akan ada kekurangan yang lebih besar untuk proses seleksi. Jika mereka melakukannya, maka dia akan menghargai pertanyaan-pertanyaan itu.
theMayer

1
Mengapa "pertanyaan 3" tidak dapat diatasi dengan menanyakan sesuatu seperti, "Apakah kita perlu keunikan yang benar-benar terjamin atau kemungkinan tabrakan yang sangat, sangat rendah?" dan, "Seberapa amankah ini harus dilakukan? Apakah kita perlu berasumsi bahwa seorang penyerang akan mencoba untuk mematahkan mekanismenya? Jenis serangan apa yang kita khawatirkan?" Jawaban atas pertanyaan-pertanyaan itu harus mengklarifikasi apakah penanya memahami masalah ini dan apa yang mereka harapkan.
jpmc26

12

Jadi, mengingat bahwa ini adalah pertanyaan wawancara dan bukan skenario kehidupan nyata yang sebenarnya, saya percaya pendekatan yang benar (dan mungkin apa yang pewawancara cari) adalah mengajukan pertanyaan klarifikasi, atau menulis "Tidak bisa dilakukan "dan terus maju. Inilah sebabnya.

Apa yang Pewawancara Bertanya:

Tulis fungsi yang dijamin tidak akan pernah mengembalikan nilai yang sama dua kali. Asumsikan bahwa fungsi ini akan diakses oleh beberapa mesin secara bersamaan.

Apa yang Dibutuhkan Pewawancara:

Apakah kandidat ini secara efektif mengevaluasi persyaratan dan mencari input tambahan saat diminta?

Jangan pernah berasumsi.

Ketika seorang insinyur diberikan persyaratan (melalui SOW atau Spesifikasi atau dokumen persyaratan lainnya), beberapa sudah jelas, dan yang lain sama sekali tidak jelas. Ini adalah contoh sempurna dari yang terakhir. Seperti yang ditunjukkan oleh jawaban sebelumnya, tidak ada cara untuk menanggapi persyaratan ini tanpa membuat beberapa asumsi utama baik (a) mengenai sifat pertanyaan atau (b) seperti sifat sistem, karena persyaratan tidak dapat dipenuhi seperti yang tertulis (tidak mungkin).

Sebagian besar jawaban membuat satu upaya atau yang lain dalam memecahkan masalah melalui serangkaian asumsi. Seseorang secara khusus merekomendasikan untuk menyelesaikannya dengan cepat dan membiarkan pelanggan khawatir tentang hal itu jika itu salah.

Ini benar-benar pendekatan yang buruk. Sebagai pelanggan, jika saya memberikan persyaratan yang tidak jelas, dan insinyur pergi dan membuat saya solusi yang tidak berhasil, saya akan marah karena mereka pergi bekerja dan menghabiskan uang saya tanpa repot-repot bertanya kepada saya terlebih dahulu. Pengambilan keputusan yang berani seperti itu menunjukkan kurangnya kerja tim, ketidakmampuan untuk berpikir kritis, dan penilaian yang buruk. Ini dapat mengarah pada segala bentuk konsekuensi negatif, termasuk hilangnya nyawa dalam sistem kritis keselamatan.

Mengapa Mengajukan Pertanyaan?

Intinya jika latihan ini mahal dan menghabiskan waktu untuk membangun persyaratan yang ambigu. Dalam kasus OP, Anda telah diberi tugas yang mustahil. Tindakan pertama Anda harus meminta klarifikasi - apa yang diperlukan? Tingkat keunikan apa yang dibutuhkan? Apa yang terjadi jika suatu nilai tidak unik? Jawaban atas pertanyaan-pertanyaan ini dapat berupa perbedaan antara beberapa minggu waktu dan beberapa menit. Di dunia nyata, salah satu pendorong terbesar biaya dalam sistem yang kompleks (termasuk banyak sistem perangkat lunak) adalah persyaratan yang tidak jelas dan kurang dipahami. Hal ini menyebabkan bug yang mahal dan memakan waktu, desain ulang, frustrasi pelanggan dan tim, dan memalukan liputan media jika proyek tersebut cukup besar.

Apa Yang Terjadi Ketika Anda Menganggap?

Mengingat latar belakang saya di industri kedirgantaraan, dan karena sifat kegagalan kedirgantaraan yang sangat terlihat, saya ingin memunculkan contoh dari domain ini untuk menggambarkan poin-poin penting. Mari kita periksa sepasang misi Mars yang gagal - Mars Climate Orbiter dan Mars Polar Lander. Kedua misi gagal karena masalah perangkat lunak - karena insinyur membuat asumsi yang tidak valid, sebagian, karena persyaratan yang tidak jelas dan kurang dikomunikasikan.

Mars Climate Orbiter - kasus ini biasanya dikutip sebagai apa yang terjadi ketika NASA mencoba mengkonversi bahasa Inggris ke satuan Metrik. Namun, itu adalah representasi yang terlalu sederhana dan buruk dari apa yang sebenarnya terjadi. Benar, ada masalah konversi, tetapi itu karena persyaratan komunikasi yang buruk di tahap desain dan skema verifikasi / validasi yang tidak tepat. Lebih lanjut, ketika dua insinyur berbeda memperhatikan masalah ini karena jelas dari data lintasan penerbangan, mereka tidak mengangkat masalah ke tingkat yang tepat karena mereka menganggap itu adalah kesalahan transmisi. Seandainya tim ops misi disadarkan akan masalah ini, ada cukup waktu untuk memperbaikinya dan menyelamatkan misi. Dalam hal ini, ada kondisi logis yang mustahil yang tidak dikenali apa adanya, yang menyebabkan kegagalan misi yang mahal.

Mars Polar Lander- kasus ini sedikit kurang terkenal, tetapi mungkin lebih memalukan karena kedekatan temporal dengan kegagalan Mars Climate Orbiter. Dalam misi ini, peranti lunak itu mengendalikan pendaratan roket ke permukaan Mars. Pada titik 40 meter di atas permukaan, kaki pendarat dikerahkan untuk persiapan pendaratan. Ada juga sensor pada kaki yang mendeteksi gerakan (untuk memberi sinyal ketika mereka berdampak) untuk memberitahu perangkat lunak untuk mematikan mesin. Tebakan terbaik NASA tentang apa yang terjadi (karena ada beberapa kemungkinan kegagalan dan data yang tidak lengkap) adalah bahwa getaran acak di kaki akibat penyebarannya secara bersamaan dan secara tidak tepat memicu mekanisme penutupan 40 m di atas permukaan, yang mengakibatkan tabrakan dan penghancuran $ 110 Pesawat ruang angkasa M Kemungkinan ini diangkat dalam pengembangan, tapi tidak pernah disapa. Pada akhirnya, tim perangkat lunak membuat asumsi yang tidak valid tentang bagaimana kode ini perlu dijalankan (salah satu anggapan tersebut adalah bahwa sinyal palsu akan terlalu pendek untuk diambil, meskipun tes menunjukkan sebaliknya), dan asumsi tersebut tidak pernah dipertanyakan sampai setelah faktanya.

Pertimbangan Tambahan

Mewawancarai dan mengevaluasi orang adalah bisnis yang sulit. Ada beberapa dimensi calon yang ingin dieksplorasi oleh pewawancara, tetapi salah satu yang paling penting adalah kemampuan individu untuk berpikir kritis. Karena berbagai alasan, tidak terkecuali bahwa berpikir kritis tidak didefinisikan dengan baik, kami memiliki waktu yang sangat sulit untuk mengevaluasi keterampilan berpikir kritis.

Sebagai instruktur teknik, salah satu cara favorit saya untuk mengevaluasi kemampuan siswa untuk berpikir kritis adalah dengan mengajukan pertanyaan yang agak ambigu. Siswa yang lebih tajam akan mengambil premis yang salah dari pertanyaan, mencatatnya, dan entah menjawab premis atau menolak untuk menjawab sama sekali. Biasanya, saya akan mengajukan pertanyaan yang serupa dengan yang berikut:

Anda mengambil gambar dari tumpukan pekerjaan Anda. Gambar itu berisi berbagai info yang berbeda, tetapi poin paling penting ke permukaan horizontal dan mengatakan "Sempurna datar". Permukaannya 5 "lebar 16" panjang, dan bagian terbuat dari aluminium. Bagaimana Anda akan mengolah bagian untuk membuat fitur ini?

(Ngomong-ngomong, Anda akan terkejut dengan seberapa sering spesifikasi yang buruk seperti itu muncul di tempat kerja.)

Saya berharap bahwa siswa akan mengenali bahwa tidak mungkin untuk membuat fitur yang sempurna, dan bahwa mereka akan menyatakan ini dalam jawaban mereka. Saya biasanya akan memberikan poin bonus jika mereka mengatakan akan kembali ke desainer dan meminta klarifikasi sebelum membuat bagian. Jika seorang siswa melanjutkan untuk memberi tahu saya bagaimana mereka akan mencapai .001 planaritas atau nilai-nilai lainnya, saya memberikan nol poin. Ini membantu saya menunjukkan kepada siswa saya bahwa mereka perlu memikirkan gambaran yang lebih besar.

Intinya

Jika saya mewawancarai seorang insinyur (atau profesi serupa), saya mencari seseorang yang dapat berpikir kritis dan mempertanyakan apa yang telah ditempatkan di depannya. Saya ingin seseorang yang mengajukan pertanyaan, "Apakah ini masuk akal?" .

Tidak masuk akal untuk meminta bagian yang benar-benar rata, karena tidak ada yang namanya sempurna. Tidak masuk akal untuk meminta fungsi yang tidak pernah mengembalikan nilai duplikat, karena tidak mungkin untuk membuat jaminan seperti itu. Dalam pemrograman, kita sering mendengar ungkapan "sampah masuk, sampah keluar." Jika Anda diberikan sampah untuk persyaratan, itu adalah tanggung jawab etis Anda untuk berhenti dan mengajukan pertanyaan apa pun yang membantu Anda memperoleh maksud sebenarnya. Jika saya mewawancarai seorang kandidat, dan saya memberi mereka persyaratan yang tidak jelas, saya akan mengharapkan pertanyaan klarifikasi.


5

Menjamin keunikan sulit karena komputer tidak memiliki variabel besar tak terhingga. Tidak ada mesin Turing dunia nyata yang bisa.

Cara saya melihatnya ada dua masalah di sini, dan keduanya memiliki solusi yang mapan.

  • Konkurensi. Beberapa mesin mungkin membutuhkan nilai pada saat bersamaan. Untungnya, CPU modern memiliki built-in concurrency dan beberapa bahasa menyediakan fasilitas yang ramah pengembang untuk mengambil keuntungan dari ini.
  • Keunikan. Walaupun tidak mungkin untuk menjamin keunikan, kita dapat memiliki variabel-variabel besar yang sewenang-wenang yang dapat menyimpan nilai-nilai begitu besar sehingga sistem dunia nyata akan memiliki waktu yang sangat sulit melelahkan semua nilai unik

Inilah solusi saya di Jawa:

public class Foo {
  private static BigInteger value = BigInteger.ZERO;
  private static final Lock lock = new ReentrantLock();

  public static BigInteger nextValue() {
    try {
      lock.lock();
      value = value.add(BigInteger.ONE);
      return value;
    }
    finally {
      lock.unlock();
    }
  }
}

BigInteger adalah tipe integer ukuran arbitrer. Itu dapat tumbuh untuk memegang nilai-nilai yang cukup besar, bahkan jika tidak terbatas. Kunci memastikan konkurensi, sehingga nilai yang sama tidak dapat dikembalikan dua kali oleh dua permintaan simultan yang dilayani oleh utas terpisah.


Saya pikir asumsi bahwa kode hanya akan digunakan selama kurang dari lima ratus tahun adalah asumsi yang valid. Jika Anda hanya mengembalikan nilai yang meningkat dalam penyimpanan 64bit, Anda baik-baik saja untuk sementara waktu. Di 1 panggilan per kami, dalam 584555 tahun.
Mooing Duck

1
Paling tidak di Jawa, yaitu 2 ^ 63 nilai (jadi setengahnya). Masih lebih lama daripada ras manusia yang mungkin ada mengingat kecenderungan kita untuk saling membunuh. Bagaimanapun, saya mengambil pendekatan yang lebih teoretis. Secara realistis, 64 (atau 63) bit harus cukup.

1
@Snowman: APA?!? Solusi Anda hanya berlaku selama 250 ribu tahun?!?!? CALON BERIKUTNYA !!!!!! :-)
Bob Jarvis - Reinstate Monica

0

Saya akan mengekspos fungsi melalui port di server; untuk memanggil fungsi, mesin yang meminta meminta koneksi dan diberikan satu, sementara pada saat yang sama dialokasikan kode pengidentifikasi (nomor urut untuk kesederhanaan). Setiap kali pesan dikirim ke port yang meminta nilai unik, nilai dihasilkan dengan menggabungkan hash MD5 dari tanggal dan waktu saat ini dengan hash MD5 dari kode identifikasi.

Jika mereka menginginkan solusi yang lebih anti peluru, mereka harus menentukan persyaratan aktual mereka daripada menjadi tidak jelas tentang berbagai hal.


-1
string uniq(string machine_id) 
{
   static long u = long.MinValue;
   Interlocked.Increment(ref u);

   //Time stamp with millisecond precison
   string timestamp = DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss.fff",
                                            CultureInfo.InvariantCulture);

   return machine_id + "-" + timestamp + "-" + u;
}

Dengan cara di atas kita dapat memastikan bahwa nilai kembali berbeda meskipun ada restart atau bahkan jika dipanggil secara bersamaan dari mesin yang berbeda.


Programmer adalah tentang pertanyaan konseptual dan jawaban diharapkan dapat menjelaskan banyak hal. Melempar kesedihan alih-alih penjelasannya seperti menyalin kode dari IDE ke papan tulis: mungkin terlihat biasa dan bahkan terkadang dapat dimengerti, tetapi rasanya aneh ... hanya aneh. Papan tulis tidak memiliki kompiler
nyamuk

Terima kasih agas untuk menunjukkannya, akan berhati-hati untuk menjelaskan solusi dari waktu berikutnya
techExplorer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.