2012-04-04 33 views
15

Tôi đang bắt đầu một dự án nhỏ, về cơ bản là phiên bản nhiều người chơi (trong hơn hai người chơi) của trò chơi Battleship cổ điển.Android P2P (kết nối trực tiếp) qua Internet (phía sau NAT)

Một vấn đề mà tôi đang cố giải quyết trước khi đi sâu vào viết mã là vấn đề giao tiếp giữa nhiều người chơi. Một khả năng hiện tại là sử dụng một máy chủ HTTP trung tâm làm trung tâm giao tiếp (cùng với API C2DM của Android để cho phép truyền thông đẩy từ máy chủ HTTP đến các thiết bị). Điều này có vẻ là một giải pháp tốt đẹp, bởi vì trong lý thuyết miễn là bạn có quyền truy cập vào Internet nó sẽ hoạt động hoàn hảo, cho dù bạn đang đứng sau NAT hay không.

Tuy nhiên, giải pháp được đề xuất có bất lợi của một điểm lỗi/tải bổ sung hiện tại (máy chủ web). Vì vậy, tôi muốn thử các tùy chọn khác. Tôi nghĩ đến việc tạo các kết nối trực tiếp bằng cách sử dụng Sockets giữa các máy khách (với máy chủ web chỉ được sử dụng như một điểm gặp gỡ ban đầu), tuy nhiên điều này sẽ chỉ hoạt động tốt nếu tất cả các thiết bị trong cùng một mạng. Xét rằng hôm nay chúng tôi hầu như luôn luôn đứng sau NAT của một bộ định tuyến như thế nào tôi có thể đạt được truyền thông trực tiếp? Tôi đã đọc về đấm lỗ nhưng tôi không thể tìm thấy bất kỳ thư viện tốt mà là tài liệu (có chứa các ví dụ tốt về sử dụng) và hoạt động trên Android cho chắc chắn. Ngoài ra hầu hết (nếu không phải tất cả) kỹ thuật đục lỗ (STUN, ICE, vv ...) chỉ có sẵn với UDP, điều này là tốt cho các trò chơi nhiều người chơi âm thanh/video và thời gian thực có thể mất một số tin nhắn. dựa trên trò chơi điều quan trọng là đảm bảo việc cung cấp dữ liệu của mỗi lượt (một cái gì đó mà nó không thể trực tiếp với UDP).

Vì vậy, bất kỳ ý tưởng nào về cách đạt được lỗ đục lỗ đáng tin cậy (tốt nhất là trên TCP) giữa các thiết bị Android phía sau NAT? Nó không phải làm việc trên 100% các trường hợp (một số NAT lạ có thể không được hỗ trợ) nhưng nó sẽ là tốt đẹp nếu nó làm việc trên hầu hết các trường hợp.

+0

Giải pháp được trình bày bởi Win Myo Htet có tiềm năng tốt đẹp (nó sử dụng cơ sở hạ tầng của riêng Google). Tuy nhiên, tôi vẫn quan tâm đến một giải pháp tốt cho việc đục lỗ TCP và/hoặc UDP trên Android. – petersaints

+0

bạn đã làm gì với @petersaints? – kishu27

Trả lời

8

sử dụng xmpp qua smack trên gtalk. Bạn không phải lo lắng về máy chủ và điểm duy nhất của sự thất bại. hãy để google lo lắng về điều đó! Tôi đã viết Tetris để làm cho nó chơi với hai người chơi sử dụng gtalk như một lớp giao tiếp. http://code.google.com/p/tetrads-drop-lite/ Bạn có thể thử MUC nếu bạn muốn nhiều người chơi hơn.

+0

Tôi cũng nghĩ đến việc sử dụng XMPP. Bạn đã sử dụng phiên bản Smack nào? Dường như dự án ban đầu không được xây dựng cho Android nhưng có một số cổng. Ngoài ra, việc gửi dữ liệu qua XMPP có dễ dàng không? Bạn chỉ có thể gửi văn bản hoặc có thể gửi dữ liệu nhị phân không? – petersaints

+0

Tôi không sử dụng nhị phân nhưng nguồn cho rằng tôi phải thực hiện một vài thay đổi. Bạn có thể gửi qua tệp nhị phân dưới dạng tệp chuyển giữa hai người chơi không phải với MUC.Tuy nhiên tại thời điểm đó, việc chuyển giao nhị phân không phải là mạnh mẽ vì sự khác biệt trong cách google đã thực hiện các giao thức và thực hiện smack chính nó không phải là rất mạnh mẽ. Tin tốt là phiên bản smack mới đã được phát hành gần đây và nó đã giải quyết việc chuyển tập tin, tôi nghe nói. Tôi chưa kiểm tra mà tho. –

+0

Vâng, vâng! Điều đó có thể hiệu quả. Cảm ơn vì những lời khuyên. Bạn có thể cho biết phiên bản Smack bạn đã sử dụng là từ đây không (tôi nghĩ đây là phiên bản chính thức): http://www.igniterealtime.org/downloads/index.jsp#smack Nếu không, bạn đã sử dụng cổng Android nào? Tôi sẽ đánh dấu thư là được chấp nhận sau. Bởi vì tôi vẫn quan tâm đến kết nối TCP/UDP trực tiếp nhưng đây là một giải pháp tốt đẹp (và có thể ít hacky hơn lỗ đục lỗ). – petersaints

0

Bạn buộc phải sử dụng trung gian. Bạn có thể tra cứu Natblaster cho một cơ chế sẽ hoạt động để thiết lập các kết nối TCP giữa một số thiết bị NAT, nhưng nó không phải là thứ mà bạn có thể sử dụng trong Android mà không cần cả hai thiết bị. Và thậm chí sau đó, nó là thử nghiệm.

Tốt nhất có thể là sử dụng hệ thống nhắn tin được liên kết hiện có như jabber.

0

UDP không phải là phân phối đáng tin cậy nhưng bạn có thể làm cho nó đáng tin cậy bằng cách yêu cầu gửi gói UDP yêu cầu xác nhận được trả về. Điều này, cùng với một vài yêu cầu khác, là những gì làm cho TCP đáng tin cậy trên IP (không đáng tin cậy để bắt đầu với).

Như một lưu ý, điều này có thể thực hiện nhưng có thể sẽ tốn thời gian và chi phí/lợi ích có thể không hoạt động trong tình huống của bạn.

Các vấn đề liên quan