UDP Server Discovery - Khách hàng có nên gửi multicast để tìm máy chủ hoặc máy chủ nên gửi đèn hiệu thường xuyên không?

Question

Tôi có các khách hàng cần kết nối với một quá trình máy chủ duy nhất. Tôi đang sử dụng phát hiện UDP cho khách hàng để tìm máy chủ. Tôi có máy khách và máy chủ trao đổi địa chỉ IP và số cổng, để kết nối TCP/IP có thể được thiết lập sau khi hoàn thành khám phá. Bằng cách này kích thước gói tin được giữ nhỏ. Tôi thấy rằng điều này có thể được thực hiện theo một trong hai cách sử dụng UDP:

1. Mỗi khách hàng gửi thông điệp phát đa hướng của riêng mình để tìm kiếm máy chủ mà máy chủ sẽ phản hồi. Máy khách có thể lặp lại việc gửi thông điệp multicast này trong các khoảng thời gian đều đặn (trong trường hợp máy chủ bị hỏng) cho đến khi máy chủ phản hồi.
2. Máy chủ gửi một báo hiệu tin nhắn đa phương tiện theo các khoảng thời gian đều đặn. Các khách hàng đăng ký vào nhóm multicast và theo cách này nhận được thông điệp multicast của máy chủ và hoàn thành việc khám phá.

Trong 1. nếu có nhiều khách hàng thì ban đầu sẽ có nhiều thư được phát đa hướng (một từ mỗi khách hàng). Chỉ có máy chủ mới đăng ký và nhận tin nhắn multicast từ máy khách. Khi máy chủ đã phản hồi ứng dụng khách, máy khách ngừng gửi tin nhắn đa hướng. Một khi tất cả các máy khách đã hoàn tất việc khám phá của họ về máy chủ, không có tin nhắn multicast nào được truyền đi trên mạng nữa. Tuy nhiên, nếu máy chủ bị hỏng, thì mỗi máy khách sẽ gửi một báo hiệu tin nhắn đa phương thức trong khoảng thời gian cho đến khi máy chủ được sao lưu và có thể phản hồi.

Trong 2. chỉ máy chủ sẽ gửi báo hiệu tin nhắn đa phương thức trong khoảng thời gian đều đặn. Thông báo này cuối cùng sẽ được chuyển đến tất cả các máy khách đã đăng ký với nhóm multicast. Khi khách hàng nhận được gói tin, ổ cắm nghe UDP của máy khách sẽ bị đóng và họ không còn đăng ký với nhóm phát đa hướng nữa. Tuy nhiên, máy chủ phải tiếp tục gửi đèn hiệu đa hướng để khách hàng mới có thể khám phá nó. Nó sẽ tiếp tục gửi ra các ngọn hải đăng trong khoảng thời gian thường xuyên bất kể cho dù bất kỳ khách hàng ra yêu cầu phát hiện của họ hay không.

Vì vậy, tôi thấy ưu và khuyết điểm theo một trong hai cách. Dường như với tôi rằng # 1 sẽ dẫn đến tải nặng hơn ban đầu, nhưng tải này cuối cùng giảm xuống không. Trong # 2 máy chủ sẽ tiếp tục gửi ra một ngọn hải đăng mãi mãi.

UDP và phát đa hướng là một chủ đề khá mới đối với tôi, vì vậy tôi quan tâm đến việc tìm ra phương pháp nào sẽ là phương pháp ưa thích và điều này sẽ dẫn đến tải mạng ít hơn.

Answer 1

Tôi muốn giới thiệu phương pháp # 2, vì có khả năng (tùy thuộc vào ứng dụng) mà bạn sẽ có nhiều khách hàng hơn bạn sẽ máy chủ. Bằng cách để máy chủ gửi báo hiệu, bạn chỉ gửi một gói mỗi lần, thay vì một gói cho mỗi khách hàng.

Lợi ích khác của phương pháp này là nó giúp khách hàng dễ dàng xác định thời điểm máy chủ mới khả dụng hoặc khi máy chủ hiện có rời khỏi mạng vì họ không phải duy trì kết nối với mỗi máy chủ máy chủ hoặc tiếp tục bỏ phiếu mỗi máy chủ để tìm hiểu.

Answer 2

Cả hai đều là phương pháp khả thi ngang nhau.

Đối số cho phương pháp số 1 sẽ là nguyên tắc thông thường, khách hàng bắt đầu yêu cầu và máy chủ lắng nghe và trả lời chúng.

Đối số cho phương pháp số 2 là điểm phát đa hướng là một máy chủ có thể gửi gói và có thể nhận được nhiều khách hàng (một-nhiều), vì vậy nó có nghĩa là ngược lại # 1.

OK, khi tôi nghĩ về điều này, tôi thực sự bị dẫn đến # 2, đèn hiệu do máy chủ khởi tạo. Vấn đề với # 1 là chúng ta hãy nói rằng khách hàng phát sóng cảnh báo, và họ kết nối với máy chủ, nhưng máy chủ hoặc là ngoại tuyến hoặc thay đổi địa chỉ IP của nó.

Khi máy chủ sao lưu và gửi báo hiệu đầu tiên, tất cả khách hàng sẽ được thông báo cùng lúc để kết nối lại và toàn bộ hệ thống của bạn sẽ được sao lưu ngay lập tức. Với # 1, tất cả các máy khách sẽ phải cá nhân nhận ra rằng máy chủ đã biến mất và tất cả chúng sẽ bắt đầu phát đa hướng cùng một lúc, cho đến khi kết nối lại với máy chủ. Nếu bạn có 1000 khách hàng và 1 máy chủ, tải mạng của bạn theo nghĩa đen sẽ lớn hơn 1000 lần so với phương pháp # 2.

Tôi biết những thông điệp này có nhiều khả năng nhỏ và 1000 gói mỗi lần không có gì đối với mạng UDP, nhưng chỉ từ quan điểm thiết kế số 2 cảm thấy tốt hơn.

Chỉnh sửa: Tôi cảm thấy như tôi đang phát triển một rối loạn nhân cách chia ở đây, nhưng chỉ nghĩ về một điểm mạnh mẽ tại sao # 1 sẽ là một lợi thế ... Nếu bạn muốn thực hiện một số loại tự nhiên cân bằng tải hoặc chia tỷ lệ với nhiều máy chủ, thiết kế # 1 hoạt động tốt cho việc này. Bằng cách đó, máy chủ "sẵn sàng" đầu tiên có thể đáp ứng với đèn hiệu của khách hàng và kết nối với nó, trái ngược với # 2, nơi tất cả các máy khách chuyển sang máy chủ báo hiệu.

Answer 3

Tùy chọn # 2 của bạn có một giới hạn lớn ở chỗ nó giả định rằng máy chủ có thể giao tiếp trực tiếp nhiều hơn hoặc ít hơn với mọi khách hàng có thể. Tùy thuộc vào kiến ​​trúc mạng chính xác của hệ điều hành của bạn, điều này có thể không đúng. Ví dụ, bạn có thể phụ thuộc vào tất cả các router và phần mềm VPN và WAN và NAT và bất cứ thứ gì khác mà mọi người kết nối với nhau, thực sự có thể xử lý các gói dữ liệu multicast.

Với # 1, bạn giả sử rằng khách hàng có thể gửi gói UDP tới máy chủ. Đây là một kỳ vọng hoàn toàn hợp lý, đặc biệt là xem xét điều tiếp theo mà khách hàng sẽ làm là tạo một kết nối TCP tới cùng một máy chủ.

Nếu máy chủ ngừng hoạt động và khách hàng muốn tìm hiểu khi nào máy chủ sao lưu, hãy chắc chắn để sử dụng exponential backoff nếu không, bạn sẽ gỡ mạng xuống một cơn bão gói một ngày nào đó!

Answer 4

Tôi đã sử dụng tùy chọn # 2 trong vài lần qua. Nó hoạt động tốt cho các cấu trúc liên kết mạng đơn giản. Chúng tôi đã thấy một số vấn đề thông lượng khi UDP datagram vượt quá Ethernet MTU dẫn đến một lượng lớn phân mảnh. Vấn đề lớn nhất mà chúng ta đã thấy là phát hiện đa hướng bị phá vỡ trong các cấu trúc liên kết lớn hơn vì nhiều router được cấu hình để chặn lưu lượng multicast.

Các issue that Greg alluded to là khá quan trọng để xem xét khi bạn đang thiết kế bộ giao thức của bạn. Ngay sau khi bạn vượt qua các cấu trúc liên kết mạng đơn giản, bạn sẽ phải tìm các giải pháp cho address translation, IP spoofing và toàn bộ các vấn đề khác liên quan đến việc trao đổi từ lớp khám phá của bạn đến lớp liên lạc của bạn. Hầu hết trong số họ phải làm cụ thể với cách máy chủ của bạn xác định chính nó và đảm bảo rằng việc xác định là một cái gì đó mà một khách hàng có thể sử dụng.

Nếu tôi có thể thực hiện lại (đã bao nhiêu lần cụm từ này), tôi sẽ tìm các cơ chế khám phá dựa trên tiêu chuẩn phù hợp với hóa đơn và bắt đầu giải quyết các vấn đề bộ giao thức khác. Điều cuối cùng mà bạn thực sự muốn làm là tìm ra một lược đồ khám phá thực sự tốt để phá vỡ tuần sau khi bạn triển khai nó vì một số cấu trúc liên kết mạng không lường trước được. Google service discovery cho danh sách bắt đầu. Cá nhân tôi có xu hướng hướng tới DNS-SD nhưng có rất nhiều tùy chọn khác có sẵn.