Chỉ sử dụng RTMFP để đối sánh ngẫu nhiên (Adobe Cirrus)

Question

Tôi đang cố gắng tìm ra cách tốt nhất để thực hiện một số kết hợp ngẫu nhiên trong một trò chơi đơn giản.

Trong khi thử nghiệm với netStreams bằng Adobe Cirrus, tôi có thể dễ dàng thiết lập kết nối trực tiếp, gửi dữ liệu, văn bản, video, âm thanh tất cả bằng cách sử dụng Cirrus đó là rất tốt. Tôi tìm thấy nó khá dễ dàng để có được một kết nối P2P đơn giản đi, và nó hoạt động giống như tôi cần nó.

Nhưng tôi thực sự muốn thực hiện một tính năng mai mối ngẫu nhiên sử dụng CHỈ ti để mọi thứ là mặc dù p2p ...

Làm thế nào tôi sẽ đi về grabbing một peer ngẫu nhiên trong cùng một nhóm ... đó không phải là trong một trực tiếp kết nối với người khác?

một số ý tưởng:

-Tôi đã suy nghĩ có lẽ tôi có thể sử dụng sao chép đối tượng ... và khi ai đó kết nối với GroupSpecifier, tôi sau đó có thể đẩy đối tượng khác vào mảng chia sẻ này mà có peerID địa phương và tình trạng của họ . sau đó tôi chỉ có thể thay đổi mảng khi họ trong một trò chơi. Nhưng sau đó im lo lắng không có đảm bảo rằng mục nhập của họ sẽ bị xóa nếu người đó chỉ đóng cửa sổ web.

-Tôi cũng nghĩ đến việc chỉ thực hiện "bài đăng" cho nhóm chứa cận cảnh và các đồng nghiệp khác có thể tải bài đăng ... và những người không có trong trò chơi sẽ thử và kết nối lại trực tiếp. Sau đó, bên đó sẽ kết nối với họ. vì vậy sau đó họ sẽ được cả hai trong các kết nối trực tiếp với nhau. Nhưng sau đó tôi cảm thấy nếu có khả năng 100 người đang "sẵn sàng" ... nhận bài đăng ... thì tất cả họ đều cố gắng và kết nối với một người, sau đó nó có thể gây ra vấn đề.

-Ngoài ra, tôi đã nghĩ đến việc chỉ làm sendToNearest ... nhưng không phải là cách tốt nhất để kết hợp mọi người ... bởi vì bạn chỉ có thể có rất nhiều hàng xóm tôi nghĩ ... nếu có 1000 người trong nhóm. bạn sẽ chỉ có thể kết nối với một vài đồng nghiệp thực sự được coi là hàng xóm của bạn đúng không? Sau đó về cơ bản bạn có thể kết thúc chỉ phù hợp với cùng một 5-10 người hoặc tuy nhiên về mặt kỹ thuật được coi là một người hàng xóm.

Answer 1

Tôi không nghĩ có cách nào để tránh hết giờ và thử lại khi kết hợp các nút cho rằng 1) có độ trễ mạng không xác định và biến, và 2) kết nối có thể tham gia và rời khỏi vào thời điểm không xác định.

Vì vậy, bất kỳ nút cố gắng kết nối tới nút khác phải giữ các thông số trạng thái sau:

• Tôi phù hợp với một nút
• Tôi có một yêu cầu trận đấu nổi bật
  • yêu cầu trận đấu xuất sắc của tôi là đến nút X

Phải từ chối đến yêu cầu đối sánh nếu một trong hai yêu cầu đầu tiên là đúng (trừ khi yêu cầu đến từ nút X và tôi có yêu cầu xuất sắc cho cùng một nút). Nó chỉ có thể yêu cầu một trận đấu nếu cả hai đều là sai. Ngoài ra, một khi phù hợp, họ có thể cần phải thăm dò ý kiến ​​đối tác của họ hoặc xem để ngắt kết nối tin nhắn và trả lời một cách thích hợp (quay trở lại giai đoạn phù hợp, hoặc thoát ra, bất kể ứng dụng nào cần).

Trường hợp đó, bạn có thể giảm thiểu lưu lượng mạng cần thiết để đồng bộ hóa các nút bằng cách tạo thuật toán sắp xếp sao cho tất cả các nút biết trước thời gian phù hợp nhất và cố gắng kết nối trực tiếp với chúng phù hợp nhất với lưu lượng truy cập mạng tối thiểu (không có thông báo đăng trên truyền hình, không phải các lần thử ngẫu nhiên).

Chìa khóa cho điều này sẽ là peerID, mỗi nút trong một NetGroup tự động nhận được. Khi một nút nhận được một thông điệp NeighborConnect, nó cũng chứa một peerID duy nhất của nút lân cận. Nói cách khác, mỗi nút có một tên duy nhất (điều đó xảy ra về cơ bản là một số ngẫu nhiên lớn) và biết tên duy nhất của tất cả các nút khác.

ID ngang hàng này dài, giống như 256 bit. Bạn có thể tạo thứ tự sắp xếp với nó - có lẽ giống như: xem xét 32 bit đầu tiên dưới dạng int, XOR peerID nút từ xa với peerID của riêng bạn và sắp xếp các nút từ xa từ thấp nhất đến cao nhất.

Vì vậy, bây giờ mỗi nút có ý tưởng tương tự về những người mà họ sẽ kết nối tới (mặc dù sẽ có sự khác biệt, ví dụ, dựa trên thông báo ngắt/kết nối truyền qua nhóm). Các nút sẽ đi qua danh sách được sắp xếp để kết nối với các kết quả phù hợp nhất của chúng, có thể với một số thời gian chờ ngẫu nhiên giữa các lần kết nối không thành công.

Đây có lẽ không phải là giải pháp lý tưởng - có thể tồn tại một giải pháp tốt hơn, nhưng tôi tưởng tượng nó tốt hơn là thử các nút ngẫu nhiên hoặc sử dụng các tin nhắn quảng bá.