khi nào sử dụng dịch vụ in hai mặt?

Question

Vâng, tôi biết rằng trong một hợp đồng song công dịch vụ có thể gửi tin nhắn cho khách hàng, nhưng tôi muốn biết khi nào thực sự hữu ích.

Tôi có một ứng dụng phổ biến gửi yêu cầu đến dịch vụ để lấy dữ liệu từ cơ sở dữ liệu, chèn dữ liệu ... v.v. Tôi cần lưu trữ tệp khoảng 40MB trong cơ sở dữ liệu, vì vậy tôi cần một hiệu suất tốt. Vì lý do này, tôi muốn sử dụng ràng buộc net.tcp với chế độ truyền trực tiếp, nhưng vấn đề là một dịch vụ song công net.tcp không thể sử dụng chế độ truyền trực tiếp.

Vì vậy, tôi nghĩ rằng tôi có một số tùy chọn.

1.- nghiên cứu nếu tôi thực sự cần một hợp đồng song công cho loại ứng dụng này. Có lẽ trong một ứng dụng trò chuyện, ví dụ, nó có ý nghĩa hơn một hợp đồng song công bởi vì máy chủ có lẽ cần phải thông báo cho khách hàng khi một liên hệ được kết nối ... vv Nhưng trong một máy khách chung truy cập vào một cơ sở dữ liệu, là cần thiết một hợp đồng song công? loại hoạt động nào có thể cần một hợp đồng song công? 2.2 Tùy chọn khác không có hợp đồng song công, nhưng thực hiện một hợp đồng song công trong máy chủ và các hợp đồng khác trong máy khách, vì vậy khi một khách hàng kết nối với dịch vụ, dịch vụ sẽ nhận được thông tin cần thiết để kết nối với dịch vụ của khách hàng. Nhưng, đây có phải là cách tốt để tránh một hợp đồng song công không?

3.- Thực sự cho ứng dụng của tôi, tôi cần tcp thay vì HTTP kép cho phép một chế độ truyền trực tiếp? Những lợi thế của tcp trên HTTP về hiệu suất là gì?

Cảm ơn.

Answer 1

Phát biểu mỗi điểm:

1, 2. Tôi nghĩ rằng đối với kịch bản của bạn một dịch vụ duplex là một overkill. Như bạn nói bản thân dịch vụ song công thường hữu ích khi cả khách hàng và dịch vụ cần phải thông báo cho nhau một cách liên tục, những gì bạn đang làm, nhận nhiều dữ liệu vào/ra khỏi cơ sở dữ liệu dường như không phải là trường hợp tốt để sử dụng giao tiếp song công. Về việc netTcpBinding không cho phép Truyền trực tuyến với hai mặt, bạn chỉ có thể trả về một mảng byte (byte[]) thay vì một luồng. 40 MB là rất nhiều, nhưng tôi không nghĩ rằng Streaming sẽ nhất thiết phải đạt được hiệu suất đáng kể so với dịch vụ song công sẽ trả về một mảng byte (tùy thuộc vào bạn để kiểm tra từng thiết lập và so sánh kết quả). Vì vậy, bạn có một vài tùy chọn ở đây, không stream và trả về một mảng byte (bạn có thể làm điều này với dịch vụ duplex của bạn) hoặc bạn có thể quên làm cho duplex dịch vụ của bạn vì dường như không phải là trường hợp mạnh mẽ cho bạn để làm cho nó đôi, và chỉ trả lại một Stream:

[OperationContract] 
Stream RetrieveFile(long _fileId); 
[OperationContract] 
long SaveFile(Stream _stream); 

3.netTcpBinding có một lợi thế đáng kể hiệu suất trên bindings HTTP, nhưng nó đi kèm với một mức giá, chủ yếu là vì các cổng TCP của nó đôi khi bị chặn bởi tường lửa internet, mặc dù bạn có thể sử dụng netTcpBinding qua internet, nhưng không phải là recommended. Chọn một ràng buộc phụ thuộc vào những gì bạn đang muốn làm, nếu khách hàng của bạn sẽ tiêu thụ dịch vụ của bạn qua internet, thì netTcpBinding không phải là một ý tưởng hay (các cổng TCP bị chặn, tường lửa, vv), nhưng nếu khách hàng của bạn đang tiêu thụ dịch vụ trong cùng một mạng (LAN) sau đó netTcpBinding là sự lựa chọn hợp lý nhất. wsDualHttpBinding (không hỗ trợ phát trực tiếp: @) là một lựa chọn tốt nếu bạn muốn sử dụng dịch vụ song công (tương đương với PollingDuplexHttpBinding trong Silverlight) hoặc bất kỳ ràng buộc dựa trên HTTP nào khác nếu bạn cho ý tưởng về dịch vụ hai chiều.

Một số điều có thể giúp bạn ra ngoài, so sánh hiệu suất của bindings WCF khác nhau:

http://blog.shutupandcode.net/?p=1085

http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html

Và về Truyền dữ liệu lớn với WCF qua HTTP, theo các tác giả, cả hai mẫu đã được kiểm tra với tối đa 2GB dữ liệu:

http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/

http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP

Bạn không nên nghĩ rằng bạn phải sử dụng netTcpBinding hoặc bạn phải sử dụng chuyển Truyền cho dịch vụ của bạn, netTcpBinding chỉ ngày càng trở nên performant hơn bindings HTTP sau khi bạn kích hoạt throttling và cấu hình một số tính chất mức độ socket. Và phát trực tuyến 40 MB sẽ không đạt được hiệu suất đáng kể so với chuyển vùng đệm. Vì vậy, bạn có rất nhiều lựa chọn và rất nhiều sự cân bằng để thực hiện. Không có màu đen và trắng và đúng hay sai, đó là cách bạn tùy chỉnh dịch vụ của mình cho phù hợp với nhu cầu của bạn nhất, hầu hết các giải pháp sẽ hoạt động. Scenrio của bạn rất phổ biến và có rất nhiều nội dung trực tuyến về chuyển dữ liệu lớn trong WCF, nghiên cứu thêm;)

Answer 2

Bạn cần hai mặt nếu bạn muốn triển khai mẫu gọi lại. Gọi lại có nghĩa là khách hàng không biết khi một số sự kiện xảy ra trong máy chủ.

Nếu bạn không biết khi sự kiện xảy ra, bạn có hai lựa chọn để thực hiện:

1. Polling - gửi yêu cầu mỗi phút X để kiểm tra xem sự kiện đã xảy ra. Máy chủ phải trả lại chi tiết sự kiện (nếu điều đó xảy ra) hoặc trả về cờ nói rằng bạn cần phải tiếp tục gọi điện. Máy chủ cũng có thể trả về thời gian chờ được đề xuất trong các tình huống nâng cao.
2. Gọi lại - khách hàng gửi một số dạng mô tả máy chủ nên làm gì nếu sự kiện xảy ra. Đây có thể là con trỏ để hoạt động trong C, ủy nhiệm trong .NET hoặc lược đồ điểm cuối trong WCF. Máy chủ nhớ thông tin đó và thực hiện cuộc gọi từ phía họ khi thời gian đến.

Như bạn có thể thấy duplex/callback có nghĩa là tại một số máy chủ điểm hoạt động như máy khách (khởi tạo giao tiếp) và đây là một thay đổi lớn.

Giao tiếp song công WCF có thể yêu cầu cấu hình mạng đặc biệt vì trong nhiều trường hợp mạng cho phép bạn gọi các dịch vụ bên ngoài (bạn làm việc với tư cách khách hàng) nhưng cấm tài nguyên bên ngoài gọi cho bạn (dịch vụ bên ngoài hoạt động như khách hàng). Điều này được thực hiện cho mục đích bảo mật.

Quay trở lại với câu hỏi của bạn:

1. Bạn không cần phải song nếu bạn chỉ cần tải lượng lớn dữ liệu. Bạn có thể cần nó nếu bạn muốn nắm bắt các cập nhật đã xảy ra trong máy chủ và thông báo cho khách hàng. Song công nên hoạt động cho Trò chuyện vì trong trò chuyện có nhiều tình huống khi khách hàng cần được thông báo với những thay đổi do người khác giới thiệu.
2. Điều bạn mô tả là biến thể song công của kênh song công. Bạn nên sử dụng thực hiện song công được chứng minh và thử nghiệm được thực hiện bởi MS Nếu bạn muốn máy chủ gọi phương thức của bạn. Nếu không, tùy chọn của bạn là bỏ phiếu.
3. Bạn nói đúng, bạn cần tcp + chế độ truyền trực tiếp để xử lý lượng dữ liệu lớn.TCP sử dụng serialization nhị phân mà là nhỏ gọn hơn so với serialization văn bản + với TCP bạn không cần phải gửi bất kỳ tiêu đề HTTP hoặc phong bì SOAP. Vô hiệu hóa bảo mật nếu bạn không cần nó. Nó có tác động hiệu suất lớn.