2012-01-20 31 views
6

Tôi gặp vấn đề mà tôi không thể hiểu được.Flash lạ AS3 xml Hành vi ổ cắm

Để hiểu nó tôi đã viết một máy khách socket trên AS3 và một máy chủ trên python/xoắn, bạn có thể thấy mã của cả hai ứng dụng dưới đây.

Hãy khởi chạy hai clients cùng một lúc, sắp xếp chúng để bạn có thể nhìn thấy cả hai cửa sổ và nhấn nút kết nối trong cả hai cửa sổ. Sau đó nhấn và giữ nút bất kỳ.

Những gì tôi đang mong đợi:

khách hàng với nút ép gửi một thông điệp "một số dữ liệu" đến máy chủ, sau đó máy chủ sẽ gửi thông điệp này đến tất cả các khách hàng (kể cả người gửi ban đầu).

Sau đó, mỗi khách hàng di chuyển sang phải nút 'connectButton' và in thông báo vào nhật ký theo thời gian theo định dạng sau: "min: secs: mili giây".

gì đang xảy ra sai:

Các chuyển động được mịn màng trong client gửi đi các tin nhắn, nhưng trong tất cả các khách hàng khác chuyển động là giật.

Điều này xảy ra vì thông báo cho những khách hàng đó đến muộn hơn so với ứng dụng khách gửi ban đầu. Và nếu chúng tôi có ba khách hàng (hãy đặt tên cho họ là A, B, C) và chúng tôi gửi một tin nhắn từ A, nhật ký thời gian gửi của B và C sẽ giống nhau.

Tại sao các khách hàng khác nhận được thông báo này muộn hơn người gửi ban đầu?

Nhân tiện, trên ubuntu 10.04/chrome tất cả chuyển động đều mượt mà. Hai khách hàng được giới thiệu trong các chromes riêng biệt.

windows screenshot

linux screenshot

Danh bạ nhà log, bốn khách hàng cùng một lúc:

[16:29:33.280858] 62.140.224.1 >> some data 
[16:29:33.280912] 87.249.9.98 << some data 
[16:29:33.280970] 87.249.9.98 << some data 
[16:29:33.281025] 87.249.9.98 << some data 
[16:29:33.281079] 62.140.224.1 << some data 
[16:29:33.323267] 62.140.224.1 >> some data 
[16:29:33.323326] 87.249.9.98 << some data 
[16:29:33.323386] 87.249.9.98 << some data 
[16:29:33.323440] 87.249.9.98 << some data 
[16:29:33.323493] 62.140.224.1 << some data 
[16:29:34.123435] 62.140.224.1 >> some data 
[16:29:34.123525] 87.249.9.98 << some data 
[16:29:34.123593] 87.249.9.98 << some data 
[16:29:34.123648] 87.249.9.98 << some data 
[16:29:34.123702] 62.140.224.1 << some data 

AS3 mã khách hàng, tôi rời phần duy nhất có liên quan, full code here.

 private var socket   :XMLSocket; 

     socket = new XMLSocket(); 
     socket.addEventListener(DataEvent.DATA, dataHandler); 

     private function dataHandler(event:DataEvent):void 
     { 
      var now:Date = new Date(); 
      textField.appendText(event.data + "   time = " + now.getMinutes() + ":" + now.getSeconds() + ":" + now.getMilliseconds() + "\n"); 
      connectButton.x += 2; 
     } 

     private function keyDownHandler(event:KeyboardEvent):void 
     { 
      socket.send("some data"); 
     } 

     private function connectMouseDownHandler(event:MouseEvent):void 
     { 
      var connectAddress:String = "ep1c.org"; 
      var connectPort:Number = 13250; 

      Security.loadPolicyFile("xmlsocket://" + connectAddress + ":" + String(connectPort)); 
      socket.connect(connectAddress, connectPort); 
     } 

Python server code.

+1

Chỉ là một suy nghĩ ở đây nhưng tôi đang bị ấn tượng nếu một đối tượng SWF không có tiêu điểm trong HTML nó sẽ chạy ở tốc độ khung hình thấp hơn. Điều này sẽ giải thích "choppyness", tuy nhiên trên ubuntu/chrome nó chạy tốt mà có thể là flash player trên thiết lập đó xử lý nó một cách khác nhau. Bạn đã thử nó trên các máy khác nhau và không chỉ trên cùng một máy? Tôi mơ hồ nhớ rằng tốc độ có thể giảm đáng kể xuống khoảng 2 FPS –

+0

cảm ơn bạn, tôi đã thử 2 máy khác nhau với ubuntu và 4 với widnows, tất cả như nhau. Khi tôi chạy hai máy khách, trên hai máy khác nhau (tất cả các máy khách đều có tiêu điểm), khách hàng chờ đợi dữ liệu bị chuyển động và nhật ký xấu như thế nào (như tôi đã đăng trong câu hỏi dưới đây). –

Trả lời

4

Bạn có thể gặp phải sự kết hợp của ACK delay và/hoặc Nagle's algorithm. Cả hai điều này có thể trì hoãn có chọn lọc chuyển động của dữ liệu trên một phiên TCP và việc triển khai của chúng thay đổi rất nhiều theo nền tảng.

Hãy thử sử dụng setsockopt() với TCP_NODELAY trên ổ cắm để tắt Nagle.

AFIK, Windows không cho phép bạn tắt trễ ACK trên cơ sở mỗi ổ cắm: bạn phải edit the registry và tắt tính năng này cho tất cả TCP. Vì vậy, hãy thử TCP_NODELAY trước tiên. Nếu điều đó không hoạt động, sau đó thử nghiệm với việc tắt trễ ACK. Ngay cả khi chỉnh sửa đăng ký không thực tế cho ứng dụng của bạn, chỉ cần biết liệu sự chậm trễ ACK có phải là vấn đề có thể chỉ cho bạn đúng hướng cho các công việc khác xung quanh hay không.

+0

OMG, có vẻ như nó hoạt động! Tôi đặt 'self.transport.setTcpNoDelay (True)' trong phương thức * connectionMade * trên máy chủ twissted. –

1

Tôi biết điều này hơi trễ một chút, nhưng rất có thể điều này là do thời gian cần thiết để thiết lập kết nối TCP giữa máy chủ và máy khách không khởi tạo. Ý tưởng là đã có một kết nối TCP được thiết lập giữa khách hàng khởi tạo và máy chủ (thiết lập của nó trước thông điệp của khách hàng đầu tiên), do đó, thời gian cần thiết để thực hiện bắt tay 3 cách được loại bỏ trong trường hợp đó .

Bạn có thể kiểm tra điều này theo một vài cách, dễ dàng nhất bằng cách thiết lập kết nối trước khi xử lý tin nhắn thực sự của bạn (ví dụ: bằng cách gửi thông điệp giả cho mỗi thư).

Bạn cũng có thể chuyển sang UDP nếu bạn không muốn thiết lập kết nối với từng máy khách, nhưng sau đó bạn mất độ tin cậy của TCP.

Tôi không chắc mình đã hiểu lưu ý của bạn về Linux. Bạn đang nói nó hoạt động như dự định trên Linux chứ không phải Windows? Nếu vậy, chúng tôi sẽ cần biết thêm về thiết lập của bạn, ví dụ như tất cả các khách hàng đang chạy trên cùng một máy chủ? Trong cùng một phiên bản trình duyệt?

+0

Không muộn, cảm ơn bạn. Có kết nối được thiết lập trước khi dữ liệu gửi. Tôi có thể kiểm tra nó bằng cách mở hai khách hàng (liên kết ở đầu câu hỏi) và chơi với họ. Có nó hoạt động như tôi dự định trên Linux. Cùng một máy chủ, cùng một trình phát Flash như ứng dụng khách, chrome trên cả hai. –