Giao thức mạng nào để sử dụng để thông báo nhẹ cho các ứng dụng từ xa?

Question

Tôi có tình huống này .... Giao tiếp SOAP 1.1 do khách hàng khởi tạo giữa một máy chủ và giả sử, hàng chục nghìn khách hàng. Khách hàng là bên ngoài, thông qua tường lửa của chúng tôi, chứng thực bằng giấy chứng nhận, https, vv .. Họ có thể ở bất cứ đâu, và thường có tường lửa riêng của họ, bộ định tuyến NAT, vv ... Họ thực sự là bên ngoài, không chỉ văn phòng công ty từ xa. Họ có thể ở trong mạng công ty/trường học, DSL/Cáp, ngay cả Dialup.

Khách hàng sử dụng Delphi (2005 + SOAP sửa từ năm 2007) và máy chủ là C#, nhưng từ quan điểm kiến ​​trúc/thiết kế, điều đó không quan trọng.

Hiện tại, khách hàng đẩy dữ liệu mới đến máy chủ và lấy dữ liệu mới từ máy chủ trên vòng lặp bỏ phiếu trong vòng 15 phút. Máy chủ hiện không đẩy dữ liệu - khách hàng truy cập vào phương thức "messagecount", để xem liệu có dữ liệu mới để kéo hay không. Nếu 0, nó ngủ thêm 15 phút nữa và kiểm tra lại.

Chúng tôi đang cố gắng giảm xuống 7 giây.

Nếu đây là một ứng dụng nội bộ, với một hoặc chỉ một vài chục khách hàng, chúng tôi sẽ viết một dịch vụ xà phòng "nghe" cilent, và sẽ đẩy dữ liệu vào nó. Nhưng kể từ khi họ đang ở bên ngoài, ngồi đằng sau bức tường lửa của riêng mình, và đôi khi các mạng riêng đằng sau NAT router, điều này là không thực tế.

Vì vậy, chúng tôi đang bỏ phiếu với vòng lặp nhanh hơn nhiều. 10 nghìn khách hàng, mỗi người kiểm tra messagecount của họ sau mỗi 10 giây, sẽ là 1000/giây thông điệp mà chủ yếu sẽ chỉ lãng phí băng thông, máy chủ, tường lửa và tài nguyên xác thực.

Vì vậy, tôi đang cố gắng thiết kế một cái gì đó tốt hơn so với những gì sẽ gây ra một cuộc tấn công DoS tự gây ra.

Tôi không nghĩ rằng thực tế để máy chủ gửi tin nhắn xà phòng tới máy khách (push) vì điều này sẽ đòi hỏi quá nhiều cấu hình ở phía máy khách. Nhưng tôi nghĩ có những lựa chọn thay thế mà tôi không biết. Chẳng hạn như:

1) Có cách nào để khách hàng thực hiện yêu cầu GetMessageCount() qua Soap 1.1 và nhận phản hồi, và có thể "ở lại trên đường" trong khoảng 5-10 phút để nhận thêm phản hồi trong trường hợp dữ liệu mới đến? tức là máy chủ nói "0", sau đó một phút sau để đáp ứng với một số kích hoạt SQL (máy chủ là C# trên Sql Server, btw), biết rằng khách hàng này vẫn còn "trên dòng" và gửi số lượng tin nhắn cập nhật của "5 "?

2) Có giao thức nào khác mà chúng tôi có thể sử dụng để "ping" ứng dụng khách, sử dụng thông tin được thu thập từ yêu cầu GetMessageCount() cuối cùng của họ không?

3) Tôi thậm chí không biết. Tôi đoán tôi đang tìm một số giao thức ma thuật mà khách hàng có thể gửi một yêu cầu GetMessageCount(), trong đó sẽ bao gồm thông tin cho "oh bằng cách này, trong trường hợp thay đổi câu trả lời trong giờ tiếp theo, ping tôi tại địa chỉ này ... ".

Ngoài ra, tôi giả sử rằng bất kỳ chương trình nào trong số này "giữ nguyên đường mở" sẽ ảnh hưởng nghiêm trọng đến kích thước máy chủ, vì nó sẽ cần phải giữ cho hàng nghìn kết nối mở, đồng thời. Điều đó có khả năng sẽ ảnh hưởng đến tường lửa, tôi nghĩ vậy.

Có điều gì ở đó như thế không? Hay tôi bị mắc kẹt nhiều với việc bỏ phiếu?

TIA,
Chris

CẬP NHẬT 2010/04/30:
Sau khi chứng minh được rằng có thông báo 7 giây không phải là dễ dàng và cũng không rẻ, đặc biệt là không đi ra ngoài trong những tiêu chuẩn của công ty của HTTPS/SOAP/Tường lửa , có lẽ chúng ta sẽ đưa ra một giải pháp hai pha. Phase1 sẽ có các cuộc thăm dò của khách hàng "theo yêu cầu" với GetMessageCount được thực hiện thông qua SOAP, không có gì lạ mắt ở đây. Sẽ có nút "refresh" để lấy dữ liệu mới (hợp lý ở đây, vì người dùng thường có lý do nghi ngờ rằng dữ liệu mới đã sẵn sàng, tức là họ chỉ thay đổi màu vải trong hệ thống trực tuyến, vì vậy họ biết nhấp chuột REFRESH trước khi xem tệp kê khai giao hàng trên máy tính để bàn và bây giờ họ thấy màu trong mô tả.) (Đây KHÔNG phải là ứng dụng may mặc/thời trang, nhưng bạn có ý tưởng). Khái niệm về việc có hai aps luôn được đồng bộ, với các bản cập nhật thời gian thực được đẩy từ máy chủ, vẫn còn trên bàn, sử dụng các công nghệ được thảo luận ở đây. Nhưng tôi hy vọng rằng nó sẽ được đẩy ra cho một phiên bản khác, vì chúng tôi có thể cung cấp 85% chức năng mà không cần phải làm điều này. Tuy nhiên, tôi hy vọng rằng chúng tôi có thể làm một Proof Of Concept, và có thể chứng minh rằng nó sẽ hoạt động. Tôi sẽ quay lại và đăng các cập nhật trong tương lai. Cảm ơn sự giúp đỡ của mọi người về điều này.

Answer 1

Hai bên lớn về phát triển đa tầng trong Delphi là components4developers (với sản phẩm kbmMW của họ được mô tả trong các câu trả lời Mark Robinson) và RemObjects với sản phẩm của họ RemObjects SDK (họ có một ví dụ tốt đẹp có thể tương tự như những gì bạn muốn: Push notifications for iPhone).

Trong môi trường phức tạp của bạn, UDP nhiều diễn viên có thể không cắt nó, nhưng từ góc nhìn trên nó là cạnh tranh nhất.

Nếu kết nối mở, nó có thể được sử dụng theo cách hai chiều (điều này cũng được sử dụng bởi .NET remoting và WCF), nhưng có thêm chi phí.

Bạn sẽ cần phải tìm sự cân bằng giữa giữ kết nối trực tiếp (khóa tài nguyên) và tạo kết nối mới (thời gian và thời gian chờ đợi).

--jeroen

Answer 2

tôi sẽ có một cái nhìn tại kbmMW

tôi có thể sẽ sử dụng một phương pháp tương tự như MS Exchange - kết nối và xác thực thông qua tcp/ip, sau đó thông báo về bản cập nhật (s) từ máy chủ cho khách hàng thông qua UDP, sau đó khách hàng nhận yêu cầu udp và tải xuống bản cập nhật qua tcp/ip.

(Ít nhất đó là cách tôi hiểu MS Exchange hoạt động)

Answer 3

Thông báo đẩy cho iPhone chỉ hoạt động nếu thiết bị từ xa của bạn là iPhone. Các tùy chọn khác duy nhất là giữ một kết nối mở (mặc dù chủ yếu là nhàn rỗi) hoặc thăm dò ý kiến ​​từ khách hàng.

Bạn có thể giảm chi phí bỏ phiếu bằng cách đơn giản hóa cuộc gọi. Sử dụng một hành động web đơn giản để trả lại số thư cao nhất cho khách hàng và yêu cầu khách hàng thực hiện một HTTP GET đơn giản để nhận số này. Điều này làm giảm số lượng băng thông, và giữ nó đơn giản. Nếu sau đó khách hàng cần nhận dữ liệu cập nhật, bạn có thể thực hiện một cuộc gọi xà phòng đầy đủ.

Answer 4

Bất cứ khi nào bạn có một máy chủ và hơn 10.000 ứng dụng và bạn cần phải cập nhật vài giây một lần bạn sẽ gặp sự cố. Tôi sẽ nhận thêm một vài máy chủ và giữ cho các máy khách kết nối trên một luồng nền trong máy khách mà ban đầu kết nối và sau đó đợi các thông báo đến từ máy chủ với một cơ chế duy trì được tích hợp sẵn.

Nếu bạn đang cố gắng đẩy từ máy chủ đến một khách hàng không được kết nối hiện tại, thì chúc may mắn nếu bạn không kiểm soát được môi trường khách hàng. Âm thanh với tôi như bạn bị buộc phải kết nối với khách hàng.

Answer 5

Bạn có thể thử thực hiện cuộc gọi đến máy chủ và đợi máy chủ trong một khoảng thời gian (1 phút?) Cho đến khi bạn có một số cập nhật. Bằng cách này bạn không cần kết nối từ máy chủ đến máy khách và bạn nhận được kết quả gần như tức thì cho khách hàng (nếu bạn có cập nhật trong vòng 1 phút, bạn kết thúc cuộc gọi chờ). Nó là một tương đối dễ dàng và rộng rãi (?) Được sử dụng bởi các ứng dụng web (như Gmail: nó có một kết nối nền như thế này: nếu một email mới đến bạn ngay lập tức nhìn thấy nó trong hộp thư đến của bạn!). Tôi sử dụng một cái gì đó như thế này (RemObjects):

function TLoggingViewService.GetMessageOrWait: TLogMessageArray; 
begin 
    if (Session.Outputbuffer.Count > 0) or 
    //or wait till new message (max 3s) 
    Session.Outputbuffer.WaitForNewObject(3 * 1000) 
    then 
    //get all messages from list (without wait) 
    Result := PeekMessage; 
end; 

điểm tiêu cực là: bạn giữ kết nối mở trong một thời gian dài tương đối (? Gì nếu kết nối bị mất do wifi vv) và máy chủ "tải" cao (mỗi kết nối có một chủ đề, được giữ mở: nếu bạn có nhiều khách hàng, bạn có thể thoát khỏi tài nguyên).

Chúng tôi sử dụng RemObject ở đây và sử dụng TCP + Binmessage có mức chi phí thấp hơn MUCH + HTTP và thực sự nhanh chóng! Vì vậy, nếu bạn có thể sử dụng nó, tôi thực sự có thể đề nghị điều đó! (trong trường hợp của bạn, bạn cần Remobjects cho Delphi và RemObjects cho. Net). Chỉ sử dụng SOAP nếu bạn cần kết nối các bên thứ ba và chỉ sử dụng HTTP nếu bạn cần nó do internet/tường lửa. SOAP là tốt đẹp nhưng có vấn đề hiệu suất cao và chi phí cao.

Bạn cũng có thể sử dụng kết hợp: kết nối TCP đơn giản (có chi phí thấp) trong chuỗi nền, bỏ phiếu mỗi 10 giây và đợi 5s cho dữ liệu mới.

Answer 6

Cân nhắc "phát" giao thức HTTP một chút để có được những gì bạn muốn trong khi vẫn có thể đi qua tất cả proxy và tường lửa của NAT và tường lửa có thể có ở phía máy khách.

Có mọi khách hàng thực hiện yêu cầu HTTP đơn giản cho số lượng thư theo cách sẽ ức chế bất kỳ loại bộ nhớ đệm nào (ví dụ: GET http://yourserver.org/getcount/nodeid/timeofday/sequence). Trong việc thực hiện phía máy chủ của sự chậm trễ máy chủ HTTP cung cấp câu trả lời nếu "đếm" là cùng nó được sử dụng để được (tức là: không có tin nhắn mới).

Tôi đã thực hiện việc này cho một ứng dụng kiểu Ajax chạy trong trình duyệt và hoạt động giống như một ứng dụng trò chuyện, nhưng giải pháp của bạn thậm chí có thể nhanh hơn. Tôi đã thực hiện các công cụ phía máy chủ bằng cách sử dụng máy chủ TIdHttp và cho phép tôi thực sự trì hoãn việc cung cấp câu trả lời cho các công cụ của khách hàng bằng cách đơn giản là Sleep() - ing trong chuỗi của nó. Từ phía máy khách, nó trông giống như một máy chủ đôi khi rất chậm để đưa ra câu trả lời.

Mã giả cho những thứ server-side:

function ClientHasMessages(ClientID:Integer; MaxWait:TDateTime):Boolean; 
var MaxTime:TDateTime; 
begin 
    if ClientActuallyHasMessage(ClientID) then Result := True 
    else 
    begin 
     MaxTime := Now + MaxWait; 
     while Now < MaxTime do 
     begin 
     if ClientActuallyHasMessage(ClientID) then 
      begin 
      Result := True; 
      Exit; 
      end 
     else 
      Sleep(1000); 
     end; 
     Result := False; // TimeOut 
    end; 
end; 

Ý tưởng đằng sau mã này: Nó chạy trong một thread trên máy chủ của riêng bạn, nơi nó có thể kiểm tra số lượng tin nhắn, có lẽ, đối với chi phí rất nhỏ:

• Nó không gây ra lưu lượng truy cập mạng trong khi chờ đợi.
• Nó không sử dụng CPU trong khi Ngủ.
• Nó sẽ cho phép người dùng biết về thông điệp của nó rất nhanh chóng.
• Nó cho phép khách hàng kiểm soát thời gian chờ đợi (khách hàng sẽ tăng thời gian máy chủ có thể trì hoãn câu trả lời cho đến khi nó không còn nhận được câu trả lời nữa, và sau đó lùi lại một chút - theo cách đó giao thức thích nghi với bất kỳ bộ định tuyến NAT lỗi nào mà ứng dụng khách sử dụng).
• Bạn có thể thoát khỏi với thời gian dài không có giao tiếp TCP/IP và vẫn có thể cung cấp câu trả lời ngay lập tức. 30 giây là dễ dàng thực hiện và cho khách hàng với các bộ định tuyến NAT tốt nó có thể được lâu hơn nữa.

Kích thước xuống của điều này sẽ được các yêu cầu trên máy chủ, nhưng tôi bị cám dỗ để nói rằng họ đang doable:

• thực hiện giao thức TCP/IP của máy chủ cần phải theo dõi khá một số kết nối đồng thời (mỗi khách hàng sẽ có một yêu cầu HTTP hoạt động ở tất cả các lần). Máy tính Linux NAT của tôi đang theo dõi kết nối 15K ngay bây giờ và về cơ bản nó không hoạt động, vì vậy nó có thể hoạt động.
• Máy chủ sẽ có một chuỗi mở cho mọi yêu cầu HTTP của máy khách, vào mọi lúc: Một lần nữa, Server 2008 "Workstation" tôi đang sử dụng để viết điều này (cảm ơn MSDN đã cho phép tôi thực hiện những điều thái quá) khoảng 1500 chủ đề hoạt động và nó cũng cơ bản nhàn rỗi ...
• Tùy thuộc vào công nghệ bạn sử dụng cho mã phía máy chủ MEMORY có thể là yếu tố hạn chế.

Answer 7

Tôi đã thực hiện kiểm tra hiệu suất trên các hệ thống thậm chí lớn hơn máy khách 10K của mình và khi bạn đạt đến số lượng yêu cầu/giây, bạn sẽ gặp phải sự cố với Kết nối/giây, Kết nối mở đồng thời, tường lửa trở nên chậm vv (Nhiều vấn đề tương tự như một Tracker Torrent có thể phải đối mặt).

Nếu khách hàng chỉ cần "hỏi xem có gì mới không" giao thức nhẹ nhất dễ thực hiện là UDP, nhẹ nhất tiếp theo sẽ là TCP thuần túy, cả hai đều sử dụng máy khách Indy.

Giao thức có thể thực sự đơn giản như gửi "Mọi thứ mới kể từ [yyyy-mm-dd hh: mm: ss]" đến máy chủ và trả lời bằng số 1 byte (256 câu trả lời có thể).

Với TCP, bạn sẽ có thêm lợi ích khi giữ "đường ống" mở trong vài phút và bạn có thể gửi thông báo "bất kỳ điều gì mới" cứ sau x giây. Ngoài ra với TCP máy chủ có thể "đẩy" thông tin vào đường ống (client (s)) khi một cái gì đó xảy ra, cho rằng khách hàng đang kiểm tra dữ liệu trong đường ống định kỳ.

Answer 8

Tôi sẽ cố gắng phân phối tải nhiều nhất có thể giữa một số máy chủ. Để làm được điều đó, tôi sẽ làm như sau:

1. Khách hàng đăng ký dịch vụ của bạn để nhận thông báo. Họ nhận được ID phiên hợp lệ trong một khoảng thời gian nhất định (15 phút).
2. Máy chủ sẽ chạy kiểm tra định kỳ về khách hàng đã đăng ký nào có thư đến và tạo danh sách các khách hàng như vậy (về mặt kỹ thuật, tôi sẽ đẩy nó vào một DB khác trong DMZ của bạn).
3. Bạn chạy một số máy chủ "thông báo đẩy" theo một giao thức rất đơn giản: họ nhận được truy vấn URL chứa ID phiên và phản hồi bằng phản hồi HTTP ngắn: 404 hoặc 200 có ký hiệu (đã ký) URL của máy chủ SOAP để giải quyết để lấy các tin nhắn. Để có thêm hiệu suất, bạn có thể sử dụng HTTP 1.1 và kết nối liên tục.
4. Khách hàng sẽ nhóm các máy chủ thông báo đẩy này thường xuyên như họ muốn. Vì chúng rất đơn giản và hoàn toàn chỉ đọc, chúng có thể trả lời các truy vấn rất nhanh và sẽ dễ dàng mở rộng.
5. Nếu khách hàng nhận được phản hồi 302, nó có thể kết nối với máy chủ SOAP chính xác (bạn cũng có thể sử dụng nó để phân phối tải nếu bạn muốn) và kéo các tin nhắn.

Bạn sẽ phải cẩn thận về bảo mật tại đây. Trước tiên, tôi khuyên bạn KHÔNG nên sử dụng HTTPS cho các máy chủ thông báo đẩy của bạn. Thay vào đó, bạn có thể đăng nội dung phản hồi bằng khóa phiên được trao đổi khi khách hàng yêu cầu thông báo. Khách hàng sau đó chịu trách nhiệm xác nhận câu trả lời. Đừng quên rằng bạn cần phải đăng nhập không chỉ tình trạng mà còn là URL dịch vụ SOAP.

Đó là một chút phức tạp nhưng bằng cách tách trạng thái và lưu lượng thư thực tế, bạn có thể mở rộng giải pháp của mình dễ dàng hơn nhiều. Ngoài ra, bạn sẽ không cần phải trải qua quá trình đàm phán SSL tốn kém cho đến khi bạn thực sự muốn trao đổi dữ liệu.

Answer 9

Chúng tôi sử dụng RemObjects SDK "sự kiện" cho điều này, nhưng điều này có thể không phù hợp với bạn vì

một: Nó chỉ làm việc với RemObjects sở hữu giao thức nhị phân, không SOAP (tức là khách hàng phải kết hợp mã RO)

b: Về cơ bản đó là phương pháp "giữ nguyên đường mở". do đó khả năng mở rộng cho máy khách 10K là một vấn đề tiềm ẩn.

Tôi sẽ thử một số kiểm tra chỉ để xem chi phí lưu giữ 10K ổ cắm thực sự có. Nếu tất cả những gì bạn cần là một vài hợp đồng biểu diễn của bộ nhớ máy chủ phụ, đó sẽ là một sửa chữa rẻ tiền. Và bởi vì ổ cắm được mở từ phía máy khách, nó không nên gây ra các vấn đề về tường lửa. Tường lửa tồi tệ nhất có thể làm là đóng socket, vì vậy client của bạn sẽ cần phải mở lại nó khi điều đó xảy ra.

Answer 10

Có điều gì đó không rõ trong lĩnh vực bên trái.

Tại sao xác thực chỉ được yêu cầu để nhận cờ có nội dung cập nhật đã sẵn sàng? Tại sao không có một máy bên ngoài tường lửa xác thực ... hoặc thậm chí trong đám mây ... mà không làm gì ngoài việc xử lý những yêu cầu 'có sẵn'. Sau đó, nếu một cái gì đó có sẵn có khách hàng đi qua các hoops để có được những dữ liệu thực tế. Máy chủ yêu cầu này có thể thực hiện lần truy cập 7 giây từ máy chủ thực.

Hiện tại chúng tôi đang nói rất ít dữ liệu và rất ít thời gian thiết lập cho một 'cờ' đơn giản thậm chí không đếm.

Vẫn còn hàng nghìn yêu cầu, nhưng hàng nghìn yêu cầu với chi phí tối thiểu so với yêu cầu được xác thực đầy đủ.