Исследование Сервера UDP - клиенты должны отправить многоадресные сообщения для нахождения сервера, или сервер должен отправить регулярный маяк?
Дайте этому выстрел:
SELECT name, description, ...
WHERE id IN
(SELECT id FROM table1 WHERE...)
ORDER BY
(SELECT display_order FROM table1 WHERE...),
(SELECT name FROM table1 WHERE...)
то, ГДЕ, вероятно, возьмет немного тонкой настройки для получения связанных подзапросов, работающих правильно, но основной принцип должен быть звуковым.
4 ответа
Я бы порекомендовал метод № 2, поскольку вполне вероятно (в зависимости от приложения) у вас будет гораздо больше клиентов, чем серверов. Если сервер отправляет маяк, вы отправляете только один пакет время от времени, а не по одному пакету для каждого клиента.
Другое преимущество этого метода состоит в том, что он упрощает клиентам определение момента появления нового сервер становится доступным или когда существующий сервер покидает сеть, поскольку им не нужно поддерживать соединение с каждым сервером или опрашивать каждый сервер, чтобы выяснить это.
Both are equally viable methods.
The argument for method #1 would be that in normal principle, clients initiate requests, and servers listen and respond to them.
The argument for method #2 would be that the point of multicast is so that one host can send a packet and it can be received by many clients (one-to-many), so it's meant to be the reverse of #1.
OK, as I think about this I'm actually drawn to #2, server-initiated beacon. The problem with #1 is that let's say clients broadcast beacons, and they hook up with the server, but the server either goes offline or changes its IP address.
When the server is back up and sends its first beacon, all the clients will be notified at the same time to reconnect, and your entire system is back up immediately. With #1, all of the clients would have to individually realize that the server is gone, and they would all start multicasting at the same time, until connected back with the server. If you had 1000 clients and 1 server your network load would literally be 1000x greater than method #2.
I know these messages are most likely small, and 1000 packets at a time is nothing to a UDP network, but just from a design standpoint #2 feels better.
Edit: I feel like I'm developing a split-personality disorder here, but just thought of a powerful point of why #1 would be an advantage... If you ever wanted to implement some sort of natural load balancing or scaling with multiple servers, design #1 works well for this. That way the first "available" server can respond to the client's beacon and connect to it, as opposed to #2 where all the clients jump to the beaconing server.
Я уже несколько раз использовал вариант №2. Он хорошо работает для простых сетевых топологий. Мы действительно наблюдали некоторые проблемы с пропускной способностью, когда дейтаграммы UDP превышали MTU Ethernet, что приводило к большой фрагментации. Самая большая проблема, которую мы видели, заключается в том, что обнаружение многоадресной рассылки не работает в более крупных топологиях, поскольку многие маршрутизаторы настроены на блокировку многоадресного трафика.
Проблема , которую Грег упомянул в , довольно важна, чтобы ее учитывать при проектировании ваш набор протоколов. Как только вы выйдете за рамки простых сетевых топологий, вам придется найти решения для преобразования адресов , IP-спуфинга и целого ряда других проблем, связанных с передачей обслуживания с вашего уровня обнаружения. к вашему коммуникационному уровню. Большинство из них связаны с тем, как ваш сервер идентифицирует себя, и с обеспечением того, что идентификация является чем-то, что может использовать клиент.
Если бы я мог сделать это снова (сколько раз мы произносили эту фразу), я будет искать основанные на стандартах механизмы обнаружения, отвечающие всем требованиям, и приступать к решению других проблем, связанных с набором протоколов. Последнее, что вам действительно нужно, - это разработать действительно хорошую схему обнаружения, которая прерывается через неделю после ее развертывания из-за непредвиденной топологии сети. Обнаружение службы Google для начального списка. Лично я предпочитаю DNS-SD , но есть много других вариантов.
Если бы я мог сделать это снова (сколько раз мы произносили эту фразу), я бы поискал основанные на стандартах механизмы обнаружения, отвечающие всем требованиям, и начал бы решать другие проблемы набора протоколов. Последнее, что вам действительно нужно, - это разработать действительно хорошую схему обнаружения, которая прерывается через неделю после ее развертывания из-за непредвиденной топологии сети. Обнаружение службы Google для начального списка. Лично я предпочитаю DNS-SD , но есть много других вариантов.
Если бы я мог сделать это снова (сколько раз мы произносили эту фразу), я бы поискал основанные на стандартах механизмы обнаружения, отвечающие всем требованиям, и начал бы решать другие проблемы набора протоколов. Последнее, что вам действительно нужно, - это разработать действительно хорошую схему обнаружения, которая прерывается через неделю после ее развертывания из-за непредвиденной топологии сети. Обнаружение службы Google для начального списка. Лично я предпочитаю DNS-SD , но есть много других вариантов.
для начального списка. Лично я предпочитаю DNS-SD , но есть много других вариантов. Последнее, что вам действительно нужно, - это разработать действительно хорошую схему обнаружения, которая прерывается через неделю после ее развертывания из-за непредвиденной топологии сети. Обнаружение службы Google для начального списка. Лично я предпочитаю DNS-SD , но есть много других вариантов. Ваш вариант №2 имеет большое ограничение в том, что он предполагает, что сервер может более или менее напрямую общаться со всеми возможными клиентами. В зависимости от точной сетевой архитектуры вашей операционной системы это может быть не так. Например, вы можете зависеть от того, что все маршрутизаторы и программное обеспечение VPN, а также WAN и NAT и все, с чем люди соединяют сети вместе, на самом деле могут обрабатывать многоадресные маяковые пакеты.
В пункте 1 вы предполагаете, что клиенты могут отправлять пакет UDP на сервер. Это вполне разумное ожидание, особенно с учетом того, что следующее, что клиент сделает, - это установит TCP-соединение с тем же сервером.
Если сервер выйдет из строя, и клиент хочет узнать, когда это произойдет.