Điểm:0

Windows có tự động rời khỏi các nhóm phát đa hướng không sử dụng không?

lá cờ cg

Khi khắc phục sự cố phát đa hướng, tôi không tìm thấy tài liệu tham khảo nào về ý nghĩa của các trường được lệnh này trả về:

C:\Users\Administrator>netsh int ip show tham gia level=verbose
    
 Giao diện 5: Ethernet0
    
 Địa chỉ phát đa hướng : 224.0.0.1
 Phạm vi : 0
 Tài liệu tham khảo : 0
 Phóng viên cuối cùng? : Đúng
    
 Địa chỉ phát đa hướng : 224.0.0.251
 Phạm vi : 0
 Tài liệu tham khảo : 2
 Phóng viên cuối cùng? : Đúng
    
 Địa chỉ phát đa hướng : 224.0.0.252
 Phạm vi : 0
 Tài liệu tham khảo : 1
 Phóng viên cuối cùng? : Đúng

làm gì Phạm vi, Người giới thiệuNgười báo cáo cuối cùng bần tiện?

tôi đoán Người giới thiệu có nghĩa là số lượng quy trình đang nghe nhóm phát đa hướng cụ thể đó. Trong trường hợp một ứng dụng dừng/gặp sự cố trước khi rời khỏi nhóm phát đa hướng mà nó đang sử dụng thì số đó sẽ bằng 0, nhưng thực tế nó không bị xóa khỏi danh sách và máy tiếp tục nhận luồng phát đa hướng. Có cài đặt nào ngăn chặn điều này không, ví dụ: sau một thời gian, nhóm phát đa hướng không còn được sử dụng bởi bất kỳ quy trình nào, hệ điều hành sẽ tự động rời khỏi nhóm đó?

Điều này đang xảy ra trên Windows 10 và Windows Server 2019 sử dụng (theo mặc định) IGMPv3.

Điểm:0
lá cờ cn

Tên chính thức cho việc tham gia/rời khỏi IGMP là IGMP Membership Report. Bộ định tuyến ngược dòng xử lý IGMP trên mạng đa truy cập được gọi là Querier. Nó thực sự Truy vấn định kỳ tất cả các máy chủ (224.0.0.1) để biết trạng thái thành viên nhóm thực tế của chúng.

Vì mạng đa truy cập có thể khá lớn, điều này có thể kích hoạt một luồng Báo cáo tư cách thành viên IGMP có thể áp đảo mạng hoặc chính Truy vấn; do bản chất của phát đa hướng, việc có bao nhiêu máy chủ trên mạng lắng nghe một nhóm cụ thể không thực sự quan trọng, chỉ cần một máy chủ là đủ để tiếp tục truyền phát nhóm này trên một giao diện.

Đối với vấn đề đó khi nhận được Truy vấn IGMP, tất cả các máy chủ bắt đầu hẹn giờ ngẫu nhiên và máy chủ đầu tiên hết hạn gửi Báo cáo tư cách thành viên của nó tới 224.0.0.1 để Người truy vấn và những người khác nghe. Nếu máy chủ đã biết rằng các nhóm của nó đã được báo cáo, nó sẽ hủy bộ hẹn giờ. Kiến trúc được xây dựng sao cho trong hầu hết các trường hợp, chỉ một vài máy chủ thực sự phản hồi Truy vấn. Máy chủ đã báo cáo một nhóm trong quá trình này được gọi là Trình báo cáo cuối cùng cho nhóm này.

Như bạn có thể thấy, bộ định tuyến ngược dòng không biết có bao nhiêu máy khách lắng nghe một nhóm cụ thể. Vì vậy, khi máy chủ gửi Báo cáo rời khỏi, bộ định tuyến không (và không nên theo thiết kế) ngay lập tức dừng luồng phát đa hướng này trên một giao diện vì có thể có các máy khách khác đang nghe nó. Thay vào đó, nó sẽ gửi Truy vấn cụ thể IGMP cho nhóm cụ thể này (tức là 239.0.0.1) để kích hoạt một số khách hàng khác lắng nghe nó để gửi lại Báo cáo tư cách thành viên của họ.

Vì tất cả nội dung Truy vấn/Báo cáo này được gửi không đồng bộ và không đáng tin cậy qua phát đa hướng nên có khả năng khác không là Truy vấn cụ thể này có thể không nhận được Báo cáo ngay lập tức do mất gói hoặc các sự cố khác, do đó, bộ định tuyến theo mặc định sẽ cố gắng gửi nó hai lần (trên hai Khoảng thời gian truy vấn) và chỉ khi đó nhóm phát đa hướng mới được cắt bớt trên một giao diện và luồng lưu lượng sẽ dừng lại. Điều tương tự cũng áp dụng nếu đối với Truy vấn tư cách thành viên tiêu chuẩn (trên 224.0.0.1), nhóm cụ thể không được báo cáo lại hai lần, điều này có thể xảy ra nếu phần mềm hoặc phần cứng gặp trục trặc trước khi có thể gửi Báo cáo nghỉ phép cho một nhóm.

Phạm vi như vậy là phạm vi địa chỉ phát đa hướng bắt nguồn từ thời của Giấc mơ định tuyến đa tuyến Internet toàn cầu cũ và huy hoàng và chỉ định khu vực mà nhóm này sẽ lưu thông, 0 có nghĩa là mạng cục bộ trong IPv4.

kuma avatar
lá cờ cg
_điều này có thể xảy ra nếu phần mềm hoặc phần cứng gặp trục trặc trước khi có thể gửi Báo cáo nghỉ việc cho một nhóm_ Tôi đoán trong trường hợp này, nhóm này sẽ tiếp tục xuất hiện trong đầu ra của `netsh int ip show join` với 0 tham chiếu và sẽ được nhận bởi máy tính cho đến khi tắt máy? Nếu vậy, có cách nào để ngăn chặn điều này?
Peter Zhabin avatar
lá cờ cn
Nhóm này sẽ được kernel thu thập và xóa sạch sau một khoảng thời gian nhất định. Vừa thực hiện một thử nghiệm nhanh - khởi chạy ứng dụng khách IPTV của tôi trên PC Windows và bắt đầu một số kênh. Nó xuất hiện trong `netsh int ip show join` với 2 tham chiếu, vì máy khách có hai quy trình. Sau đó, tôi đã giết nó bằng lửa, tức là tôi đã kết thúc nó một cách mạnh mẽ bằng `TerminateProcess`. Nhóm được đề cập được hiển thị với 0 tham chiếu trong khoảng 10-15 giây sau đó rồi biến mất hoàn toàn. Vấn đề thực sự mà bạn đang cố gắng giải quyết là gì?
kuma avatar
lá cờ cg
nhóm được đề cập được hiển thị với 0 tham chiếu, không bao giờ biến mất và các gói từ nhóm phát đa hướng đó được nhận vô thời hạn. Rõ ràng bộ thu gom rác không hoạt động? Làm thế nào để kiểm tra điều đó?
Peter Zhabin avatar
lá cờ cn
Trong ví dụ của bạn ở trên `224.0.0.1` là `all-hosts` và được xử lý bởi chính hạt nhân, vì vậy nó có 0 tham chiếu nhưng sẽ không bao giờ biến mất. Có thể nhóm bạn đang xem giống như thế này, bạn có thể vui lòng cụ thể hơn không, tức là cung cấp địa chỉ nhóm và kịch bản sử dụng?
kuma avatar
lá cờ cg
phát đa hướng mà tôi đang đề cập đến không được chụp trong ảnh chụp màn hình. Đó là một phát đa hướng có phạm vi hành chính (ví dụ: 239.10.10.10). Kịch bản của tôi rất giống với kịch bản trước đó của bạn: đã khởi chạy một ứng dụng tùy chỉnh đã tham gia một nhóm phát đa hướng, sau đó tôi chấm dứt ứng dụng một cách mạnh mẽ và nhóm phát đa hướng được đề cập được hiển thị với 0 tham chiếu, không bao giờ biến mất và các gói từ nhóm đó được nhận vô thời hạn. Tôi không hiểu tại sao điều này lại xảy ra và tại sao làm điều tương tự với VLC (chấm dứt ứng dụng một cách mạnh mẽ) lại khiến nhóm biến mất ngay lập tức.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.