Menjaga komunikasi antara dua klien meskipun alamat IP mereka berubah
Saya mencoba mencari tahu apakah mungkin memiliki skenario seperti ini:
Katakanlah kita memiliki dua orang, Alice dan Bob. Alice ingin mengirim beberapa data (tidak peduli apa data ini) ke Bob, dan sebaliknya. Saya tahu bahwa WebRTC dapat digunakan untuk bertukar pesan tanpa server, tetapi itu mengharuskan Alice dan Bob mengetahui alamat IP satu sama lain. Sekarang, relatif mudah bagi Alice dan Bob untuk membagikan alamat IP mereka satu kali, untuk menginisialisasi koneksi, tetapi apa yang terjadi jika salah satu dari mereka terhubung ke jaringan yang berbeda; Mungkinkah Bob ada di kedai kopi, misalnya, dan alamat IP-nya jadi berbeda? Sambungan yang diinisialisasi sebelumnya tidak akan ke alamat IP saat ini, jadi mereka harus menginisialisasi ulang sambungan; tapi bagaimana caranya?
Bagi saya tampaknya sudah perlu ada semacam komunikasi yang sudah ada sebelumnya antara keduanya sehingga mereka dapat berbagi alamat IP mereka, tetapi mengapa tidak hanya berkomunikasi melalui metode mereka mengkomunikasikan alamat IP mereka? Atau, mungkin ada server yang menghubungkan keduanya, tetapi itu mengalahkan bagian sistem tanpa server.
Jadi, adakah cara untuk mempertahankan komunikasi antara dua klien bahkan jika mereka kebetulan mengubah jaringan, dan dengan demikian alamat IP? Mungkin ada metode yang lebih pasti untuk mengidentifikasi perangkat daripada alamat IP mereka, seperti yang pernah saya lihat di jawaban SO ini , tapi sudah bertahun-tahun, jadi mungkin ada sesuatu yang baru? Saya akan menerapkan ini di JS, di beberapa perangkat / OS, jadi jawaban itu mungkin tidak akan berfungsi. Ide / contoh apa pun akan sangat dihargai; Saya terutama ingin tahu apakah ini mungkin, dan, jika demikian, bagaimana caranya.
Jawaban
Ya, itu mungkin.
Anda perlu menggunakan FQDN(atau sub-domain) sebagai ganti IP Addressdan DNSserver, dan util atau alat sisi klien untuk memperbarui catatan DNS saat Alamat IP berubah.
Ada solusi gratis di web seperti no-ip.com, cloud-flaredan lain-lain.
Jawaban Sederhana
Tidak, meskipun mungkin, ini tidak realistis dan tidak diperlukan. Lihat penjelasan saya yang lebih panjang di bawah ini. Selain itu, jika Anda benar-benar ingin melakukan ini, meskipun dapat dilakukan melalui QUIC , kemungkinan tidak diperlukan (seperti yang dijelaskan di bawah).
Jawaban / Pertanyaan Lebih Panjang untuk dipikirkan
Singkatnya, ini bukanlah fitur WebRTC yang dibutuhkan. Izinkan saya mengajukan pertanyaan kepada Anda:
Alice dan Bob berada di saluran data, bertukar pesan obrolan melalui WebRTC. Untuk membuat koneksi WebRTC, Anda perlu menggunakan server es ( tautan pertama , tautan kedua ) untuk mendapatkan Alice dan Bob, mengutip Wikipedia:
... untuk menemukan cara agar kedua komputer dapat berbicara satu sama lain secara langsung secepat mungkin ..
Ini berarti ia akan menggunakan alamat IP Alice saat ini untuk membuat penawaran kepada Bob melalui server STUN atau TURN. Jika, seperti yang Anda katakan, Alice mengubah alamat IP, dia perlu mengubah lokasi. Itu berarti dia harus bergerak dalam jarak yang cukup agar alamat IP bisa berubah. Dalam praktiknya, ini mungkin berarti dia masuk ke mobil dan mengemudi ke suatu tempat. Jika tidak, dia menelepon Uber atau taksi atau mengendarai sepedanya. Dalam sebagian besar skenario ini, dia harus menutup komputernya, lalu mengakhiri koneksi p2p. Jika, karena sihir aneh, dia tidak menutup komputer / koneksi, browser kemungkinan besar akan menyegarkan, sehingga menyambungkan kembali ke saluran data WebRTC dari alamat IP baru . Kapan Anda perlu membuat saluran data WebRTC dan menangani perubahan IP? Penjelasan panjang sampai pada kesimpulan, klien mengubah alamat IP tanpa mengakhiri / mengatur ulang koneksi tidak terjadi dalam praktiknya.
Jika Anda ingin mencari alternatif lain, berikut beberapa contohnya:
ALTERNATIF
Menambahkan pendengar acara IP ★
Sekarang ini bukan variabel global sebenarnya yang dapat Anda periksa, tetapi Anda dapat menggunakan API online (beberapa tercantum di sini ) untuk memeriksa alamat IP pengguna, menyimpannya dalam variabel (atau Penyimpanan lokal), dan memeriksa apakah IP berubah . Dalam satu perulangan, Anda akan melakukan beberapa logika sederhana untuk memeriksa Jika ya, Anda menyetel ulang koneksi WebRTC, jika tidak, Anda tetap menjalankan perulangan.
Menggunakan server "perpipaan"
Anda dapat mengatur obrolan sederhana dengan menggunakan server http / https, yang sudah disiapkan, dijelaskan di sini , yang disebut server perpipaan. Anda dapat melihat artikel untuk informasi lebih lanjut, tetapi artikel ini mempromosikan sistem obrolan tanpa server (dapat digunakan tanpa membuat server) yang tidak mengalami kesulitan dalam mengubah alamat IP. Namun, Anda perlu mengetahui ID rekan, dan mereka perlu mengetahui ID Anda, yang secara efektif membuat solusi menjadi usang karena Anda perlu memiliki semacam komunikasi sebelum membuat obrolan sederhana ini.
Menggunakan Node.js, Websockets, dan / atau Socket.io ★
Jika Anda ingin membuat aplikasi obrolan sederhana atau membuat saluran data, Node.js dan Socket.io adalah caranya. Ini sangat sederhana, namun ini melibatkan server, itulah sebabnya saya meninggalkannya untuk yang terakhir. Namun, saya sangat merekomendasikan ini untuk kemudahan dan kesederhanaan, dan tidak bergantung pada alamat IP. Lihat di sini untuk perendaman awal yang sangat baik ke dalam Node.js dan kerangka kerja Express. Saya jauh dari pakar Websockets, tetapi MDN selalu merupakan tempat yang baik untuk memulai. Betapapun bagusnya Websockets, saya pikir Socket.io jauh lebih mudah untuk pemula, jadi jika Anda bersedia mengorbankan sedikit kecepatan daripada kesederhanaan, Anda harus mulai dari sini . Ini semua adalah titik awal obrolan sisi server yang bagus.
Tautan
Jawaban Sederhana
Migrasi koneksi QUIC
Pendengar IP
SO Pertanyaan ,
Server Es
Dokumen MDN , Wikipedia
Server Perpipaan
Artikel sederhana , repo Github
Node.js, Websockets, dan Socket.io
Pengaturan Node.js dan Express , pengantar Websocket , dan pengantar Socket.io
Semua alternatif yang bertanda bintang (★) direkomendasikan secara pribadi.