Giới thiệu
Phát triển Web ASP.NET được xây dựng trong ba tùy chọn để lưu trữ trạng thái phiên, cụ thể là, trong quá trình ghi nhớ, SQL Server và Server Status.
In-process memory cung cấp hiệu suất nhanh nhất, nhưng không thích hợp để sử dụng trong các máy chủ web vì dữ liệu phiên được lưu trữ trong bộ nhớ của chương trình ASP.NET.
SQL Server là một trong số tiến trình lựa chọn lưu trữ trạng thái phiên làm việc với các trang máy chủ web. Nó lưu trữ dữ liệu trong phiên cơ sở dữ liệu SQL Server. Đây là lựa chọn đáng tin cậy nhất nhưng ít thực hiện. Một vấn đề lớn với các tùy chọn này là nhà phát triển muốn bộ nhớ dữ liệu cache lấy từ cơ sở dữ liệu trong trạng thái phiên, giảm tra cứu cơ sở dữ liệu. SQL Server phiên đánh bại mục đích này, bởi vì có rất ít đạt được hiệu suất trong bộ nhớ đệm dữ liệu lấy từ cơ sở dữ liệu.
State Server là một trong số tiến trình lựa chọn lưu trữ trạng thái phiên làm việc với máy chủ web. Nó lưu trữ dữ liệu phiên trong bộ nhớ và mang lại hiệu năng tốt hơn so với SQL Server. Điều này có vẻ như một sự thỏa hiệp tốt giữa các tùy chọn trong tiến trình và các tùy chọn máy chủ SQL. Nó có một số hạn chế.
Thứ nhất, một số máy chủ web thường phụ thuộc vào máy chủ trạng thái đối với trạng thái phiên trong đó giới thiệu một điểm quan trọng duy nhất thất bại.
Thứ hai, trong một môi trường cân bằng tải, cân bằng tải có thể chuyển hướng yêu cầu của người dùng đến máy chủ web là khác nhau từ máy chủ web phục vụ yêu cầu trước đó của người dùng. Nếu máy chủ web mới giao tiếp với máy chủ trạng thái khác, trạng thái phiên gốc của người dùng sẽ không được tìm thấy và ứng dụng web có thể không hoạt động đúng.
Vấn đề này xảy ra ngay cả trên (hay còn gọi là nếp) cân bằng tải hoặc sai hoặc do máy chủ thất bại.
Thứ ba, vấn đề mà nhiều nhà phát triển không biết là máy chủ web và máy chủ trạng thái giao tiếp trong văn bản đơn giản. Kẻ nghe trộm có thể dễ dàng có được dữ liệu trạng thái phiên đi qua trên mạng. Có thể không phải là một mối đe dọa nếu tất cả các máy chủ đang chạy trong mạng nội bộ nhưng nó chắc chắn là mối lo lớn khi máy chủ web và máy chủ trạng thái được lan truyền trên internet.
Máy chủ trạng thái ASP.NET ngang hàng trình bày trong bài viết này giải quyết những vấn đề nói trên trong khi thay thế Microsoft cung cấp máy chủ trạng thái.
Tổng quan
Ý tưởng đằng sau ngang hàng đến máy chủ trạng thái là đơn giản - để cho các máy chủ trạng thái về mạng lưới an toàn giao tiếp và truyền dữ liệu giữa các trạng thái phiên khi cần thiết, như hình dưới đây.
Thiết kế này cải thiện khả năng mở rộng bởi vì các máy chủ web có thể chia sẻ nhiều máy chủ trạng thái, loại bỏ một điểm duy nhất của thất bại. Hơn nữa, nếu cân bằng tải sai hoặc cố tình chuyển hướng người dùng đến máy chủ web khác gắn liền với máy chủ trạng thái riêng biệt, trạng thái phiên làm việc của người dùng sẽ được yêu cầu từ máy chủ mà trạng thái phục vụ yêu cầu trước đó của người dùng.
An ninh cũng được cải thiện ngang nhau có thể được cấu hình để mã hóa dữ liệu phiên trong khi chia sẻ trạng thái phiên. Truyền dữ liệu giữa máy chủ web và máy chủ trạng thái vẫn không được mã hóa nhưng các cuộc tấn công nghe lén có thể được loại bỏ bằng cách giữ máy chủ web và máy chủ trạng thái liên kết trong mạng đáng tin cậy hoặc trên cùng máy tính.
Ngang hàng đến máy chủ trạng thái là hoàn toàn tương thích ngược với các máy chủ Microsoft cung cấp trạng thái và đi kèm với tất cả các lợi ích nói trên.
Cài đặt
Để biên dịch và cài đặt máy chủ trạng thái:
1. Tải về các tập tin nguồn.
2. Mở Solution trong Visual Studio. ( Visual Studio 2008 sẽ mở ra thuật sĩ chuyển đổi. Hoàn thành Wizard.)
Máy chủ trạng thái có hai hướng. Một chạy như ứng dụng giao diện điều khiển và một chạy khác như một dịch vụ windows . Dự án StateService biên dịch như dịch vụ windows và có thể được cài đặt và gỡ bỏ cài đặt với tập tin install_service.bat và uninstall_service.bat. Dự án ConsoleServer chạy các dịch vụ như giao diện điều khiển ứng dụng, dễ dàng hơn nhiều để kiểm tra và sửa lỗi. Cả hai dự án chia sẻ nguồn và các chức năng tương tự giống nhau.
3. Mở thuộc tính windows cho các dự án mà bạn muốn xây dựng.
4. a. Nếu sử dụng Visual Studio 2005, thêm NET 2.0 trong những biểu tượng lặp có điều kiện trường tab Build.
b. Nếu sử dụng Visual Studio 2008, chọn . NET Framework 3.5 trong Target Framework trường của tab ứng dụng.
5. Build Project.
6. Nếu bạn Build Project StateService, điều hướng đến thư mục đầu ra và chạy install_service.bat cài đặt dịch vụ.
7. Nếu bạn đã chạy dịch vụ trạng thái của Microsoft trên máy tính, ngăn nó lại.
8. Nếu bạn Build và cài đặt dịch vụ windows, bạn có thể bắt đầu Peer to Peer dịch vụ trạng thái trong danh sách dịch vụ. Nếu bạn xây dựng giao diện điều khiển máy chủ, chạy ConsoleServer.exe hoặc chỉ đơn giản là bắt đầu gỡ lỗi từ Visual Studio.
9. Bây giờ bạn có thể kiểm tra và chạy ứng dụng web mà bạn có với các máy chủ trạng thái đang hoạt động.
Để thêm các máy chủ ngang hàng:
1. Sao chép các tập tin thực thi biên dịch và các tập tin cấu hình ứng dụng cho máy tính khác trên mạng.
2. Mở tập tin cấu hình và thêm đồng đẳng mới trong phần <Peers>. Ví dụ, để cấu hình máy chủ trạng thái để kết nối đến máy chủ trạng thái hoạt động trên máy tính có tên SV3 với một số cổng ngang hàng 42.425, bạn sẽ thêm <add key="MyPeer" value="pc2:42425" /> đến phần <Peers>.
3. Bạn có thể bắt đầu máy chủ trạng thái trên máy tính và nó sẽ liên kết với các máy chủ trạng thái khác(s) trên mạng.
4. Đó là up to you để thiết lập mạng trong bất kỳ cấu trúc liên kết bạn muốn. Ví dụ, hãy xem xét mạng máy chủ ba trạng thái như hình dưới đây, mỗi máy chủ trạng thái trên mỗi máy sẽ có cấu hình như sau:
Bạn có thể chạy nhiều Peers máy chủ giao diện điều khiển trên cùng máy tính nhưng mỗi giao diện điều khiển máy chủ phải có một cổng máy chủ web độc đáo và thiết lập cổng ngang hàng.
Bằng cách nào để hoạt động
Máy chủ Microsoft cung cấp trạng thái các công việc như hình dưới đây:
Peer to Peer máy chủ trạng thái hoạt động chính xác như được mô tả ở trên, trừ khi máy chủ trạng thái không có phiên \yêu cầu, trong trường hợp này nó yêu cầu trạng thái phiên từ mạng trước khi trả lời, như minh họa dưới đây:
Nếu trạng thái phiên yêu cầu không được chuyển trong một khoảng thời gian quy định, máy chủ trạng thái giả định trạng thái phiên không tồn tại trên mạng và tiến trình thu được để xử lý yêu cầu máy chủ web không có trạng thái phiên. Lớp GetTransferMessage đại diện cho các thông điệp được phát trên mạng khi một nút được yêu cầu phiên. Peers duy trì kết nối giữa chúng chủ yếu để chuyển tiếp tin nhắn này. Chuyển trạng thái phiên xảy ra ngoài băng tần của mạng ngang hàng.
Thực hiện Ghi chú
Kỹ thuật lập trình khác được sử dụng để thực hiện các khía cạnh khác nhau của máy chủ trạng thái. Một số đáng chú ý được đánh dấu dưới đây.
Nền tảng
Máy chủ trạng thái được viết bằng C # 2.0, nhưng mục tiêu của NET framework 3.5 để tận dụng lợi thế của lớp ReaderWriterLockSlim. Nếu NET 2.0 được xác định, máy chủ sử dụng chậm hơn lớp ReaderWriterLock để thay thế và có thể nhắm mục tiêu .NET framework 2.0.
Protocal
Để tạo ra máy chủ trạng thái minh bạch có thể thay thế máy chủ trạng thái, tôi cần thiết để có và hiểu được các đặc điểm kỹ thuật đầy đủ của giao thức giao tiếp giữa máy chủ web và máy chủ Microsoft cung cấp trạng thái. Các bước thực hiện đến phần giao thức được diễn tả tại http://ahuwanya.net/blog/category/Peer-to-Peer-Session-State-Service.aspx .
Messaging
Máy chủ phần lớn điều hướng tin nhắn. Hệ thống tin được minh họa dưới đây:
Khi máy chủ nhận dữ liệu từ Socket, dữ liệu được tích lũy trong thể hiện của lớp HTTPPartialData hiện đang phân công đến socket. HTTPPartialData xác nhận các dữ liệu, xác định nếu dữ liệu tích lũy là thông điệp HTTP đầy đủ và kiểm tra lỗi trong dữ liệu tích lũy. Nếu có một lỗi dữ liệu (ví dụ, nếu dữ liệu không phù hợp với HTTP), toàn bộ dữ liệu tích lũy được bỏ đi và ốcket được đóng. Nếu dữ liệu là hợp lệ nhưng chưa hoàn thành,étocket đợi thêm dữ liệu đến.
Nếu dữ liệu tích lũy là thông điệp HTTP hoàn chỉnh, dữ liệu được gửi đến một đối tượng MessageFactory. Đối tượng MessageFactory kiểm tra dữ liệu để xác định lớp ServiceMessage phù hợp tạo ra. Lớp con ServiceMessage được thể hiện và thực hiện tiến trình được gọi là phương thức để xử lý tin nhắn.
Đồng thời xử lý
Một cơ chế đồng thời bi quan được sử dụng khi truy cập trạng thái phiên trong từ điển phiên, được xác định bởi lớp SessionDictionary. Một mảnh của trạng thái phiên chỉ có thể được đọc và chỉnh sửa bởi một luồng tại một thời điểm. Một Luồng tuyên bố quyền truy cập để hoạt động trên một phần của trạng thái phiên bằng cách thiết lập thuộc tính IsInUse cho đúng. Được thực hiện bằng cách gọi nguyên tử so sánh và trao đổi phương thức CompareExchangeInUse (wrapper đến NET. Interlocked.CompareExchange phương pháp hoạt động trên IsInUse tài sản). Thiết lập thuộc tính này thực sự cho phép các luồng khác biết rằng luồng đang làm việc với trạng thái phiên.
Nếu luồng khác muốn truy cập trạng thái cùng phiên và cố gắng để khai báo quyền truy cập, nỗ lực sẽ thất bại vì luồng khác đã có quyền truy cập độc quyền. Luồng sẽ tiếp tục cố gắng để có được quyền truy cập, và cuối cùng sẽ có được nó khi các luồng khác truy cập. Hoạt động này khá tốt bởi vì hầu hết thời gian, chỉ có một luồng cần truy cập vào trạng thái phiên, và cũng bởi vì hầu hết các hoạt động trên trạng thái phiên mất một thời gian rất ngắn để hoàn thành. Các hoạt động xuất(chuyển nhượng) phải mất thời gian lâu hơn nữa được xử lý với một cách khác và được thảo luận trong phần quản lý tương tranh dưới đây.
TIMERS - hoặc thiếu CHÚNG
Mã này có rất nhiều các đối tượng hết hạn hoặc thời gian hết và trên những hành động nhất định phải diễn ra - đối tượng như cá nhân phiên từ điển hết hạn hoặc tin nhắn không đồng bộ thời gian chờ. Thay vì chỉ định giờ hoặc chờ đợi xử lý để theo dõi các đối tượng này - chúng được lưu trữ trong trường hợp của lớp đặc biệt được gọi là DateSortedDictionary. Đối tượng trong từ điển này đều được sắp xếp ở vị trí của nhãn thời gian được phân. Đặc biệt được đề cuộc thăm dò những ngày sắp xếp từ điển cho các mặt hàng hết hạn sử dụng và thực hiện các thao tác liên quan nếu một sản phẩm hết hạn sử dụng. Thiết kế này làm giảm đáng kể số lượng các luồng(thread) cần thiết để theo dõi hết hạn mục.
DIAGNOSTICS
Các lớp DIAGS được sử dụng để theo dõi bài viết, máy chủ đăng nhập hoạt động và phát hiện sự bế tắc. Phương thức trên lớp DIAGS có điều kiện và sẽ không biên dịch thành mã cấu hình release.
Các biểu tượng VERBOSE có thể được xác định để xem hoặc đăng nhập tất cả các hoạt động diễn ra tại máy chủ. Điều này đặc biệt hữu ích với giao diện điều khiển máy chủ mà kết quả đầu ra của thông tin này vào cửa sổ giao diện điều khiển. Nếu biểu tượng VERBOSE không được xác định, chỉ có thông tin quan trọng hay lỗi không mong muốn được hiển thị.
An ninh
Microsoft cung cấp máy chủ truyền trạng thái và nhận được sự mã hóa dữ liệu đến và đi từ máy chủ web. Điều này rất có thể đã được thực hiện vì lý do hiệu suất. Để tương thích với các máy chủ Microsoft trạng thái cung cấp, truyền dữ liệu ngang hàng đến không được mã hóa máy chủ trạng thái đến các máy chủ web. Tuy nhiên, ngang hàng đến máy chủ trạng thái có thể được cấu hình để truyền dữ liệu được mã hóa giữa các Peer. Điều này cản trở hiệu quả các cuộc tấn công nghe trộm mạng nếu máy chủ web và máy chủ trạng thái có liên quan được cài đặt trên cùng một máy tính hoặc trên mạng tin cậy.
Ví dụ, có máy chủ Web - cấu hình máy chủ Microsoft trạng thái trình bày dưới đây.
Hai máy chủ web kết nối qua internet công cộng để truy cập vào một máy chủ của trạng thái.
Sử dụng ngang hàng đến các máy chủ trạng thái, mạng có thể được bảo đảm bằng việc có các máy chủ web có các máy chủ trạng thái local của mình kết nối an toàn đến máy chủ từ xa thay mặt cho trạng thái của chúng như hình dưới đây:
Các máy chủ trạng thái local có thể được cài đặt trên cùng một máy như máy chủ web bảo mật tối đa và độ trễ tối thiểu.
Cách tiếp cận này có thể giúp trang web và trạng thái máy chủ phân phối địa lý an toàn.
máy chủ trạng thái Peer cũng cùng xác nhận lẫn nhau trong khi kết nối, để đảm bảo rằng bên kia là một đồng đẳng được ủy quyền.
Network Topologies
Kết nối giữa các peer hình thành mạng hợp lý có thể được thiết kế với cấu trúc liên kết mạng chung.
Mạng hiển thị ở trên là mạng vòng các máy chủ trạng thái ngang hàng được kết nối cá nhân đến các máy chủ web trong khi mạng B là một vòng mạng máy tính mà có cả máy chủ và máy chủ web trạng thái kết nối và chạy. Mạng máy chủ trạng thái Microsoft bị cô lập hiện tại có thể được nâng cấp để tạo thành mạng ngang hàng lớn hơn để nhìn mạng bằng cách thay thế các máy chủ Microsoft với trạng thái ngang hàng đến các máy chủ trạng thái và liên kết chúng lên như trong mạng A. Mạng lợi ích B từ các biện pháp truy cập an ninh đã đề cập trước và có phần mở rộng hơn từ bất cứ nút nào trên mạng là máy chủ web và máy chủ trạng thái ngang hàng.
Cả hai mạng sẽ vẫn hoạt động nếu một nút không thành công, không giống như trên một mạng bus, tuy nhiên như các nút được thêm vào mạng, còn phải mất tin nhắn để đi qua mạng.
Mạng C là mạng sao. Một lợi thế của việc có mạng sao là không có vấn đề bao nhiêu các nút mới được thêm vào mạng thì nó cũng chỉ mất hai bước nhảy cho một tin nhắn để đạt được bất kỳ nút trên mạng.
Mạng D là mạng của mạng ba sao đã hình thành mạng sao lớn hơn. Mạng này cũng sẽ đòi hỏi một số ít bước nhảy cho tin nhắn để đi qua mạng. Cả hai mạng bị bất lợi là nếu nút trung tâm không có, toàn bộ mạng bị lỗi.
Bằng cách kết nối các nút lá trên mạng D, mạng điện tử, mạng một phần được hình thành. Mạng điện tử là sự kết hợp thông minh của mạng vòng và mạng sao. Nếu nút trung tâm không có, mạng vẫn sẽ hoạt động và nó cũng có một số ít bước nhảy cho tin nhắn để đi qua mạng hơn trên mạng vòng.
Như đã chứng minh, các cấu trúc liên kết của mạng qua máy chủ trạng thái được giới hạn bởi trí tưởng tượng của các nhà thiết kế mạng.
Các kịch bản thú vị
Có rất nhiều kịch bản xảy ra trong các máy chủ trạng thái được xử lý sử dụng ngang hàng truyền thống đến tiến trình ngang hàng như thời gian sống được sử dụng để ngăn chặn các tin nhắn từ lưu hành vĩnh viễn trên mạng, và các định dạng tin nhắn được sử dụng bởi các peer nhận thông điệp đã được nhìn thấy trước đó, tuy nhiên, có hai tình huống đặc biệt xảy ra trong mạng ngang hàng này mà không phải là quá phổ biến.
CHUYỂN Shutdown
Để đảm bảo rằng dữ liệu phiên là không bị mất khi máy chủ tắt, tiến trình máy chủ trạng thái chuyển tất cả dữ liệu trạng thái phiên của mình với các peer kết nối trong một thời trang vòng tròn khi máy chủ ngừng hoạt động được bắt đầu.
Rebroadcasts
Một yêu cầu phiên về mạng hẹp có thể bỏ lỡ nút nắm giữ phiên giao dịch nếu nó đang được chuyển như minh họa dưới đây.
Như đã trình bày ở trên, nút 1 đang tìm kiếm phiên A từ mạng về cùng một lúc nut 4 muốn chuyển phiên đến nút 2.
Khi được thông báo từ nút 1 đến nút 2, nút 2 chuyển tiếp tin nhắn đến nút 3 bởi vì nó không có phiên.
Khi tin nhắn đến nút 3, việc chuyển giao phiên giữa các nút 4 và 2 bắt đầu và thời gian được thông báo đến nút 4, chuyển giao hoàn tất và nút 4 không còn có phiên giao dịch nữa và chuyển tiếp tin nhắn tới nút 5.
Như vậy, đi qua tin nhắn mạng mà không cần đến bất kỳ nút với phiên tìm kiếm, mặc dù phiên giao dịch tồn tại trên mạng.
Các máy chủ trạng thái giải quyết vấn đề này bằng cách có các nút gần đây chuyển phát lại phiên giao dịch tin nhắn như hình dưới đây:
Nút 4 rebroadcasts thông điệp đến nó cũng trở lại đường nó đến và cuối cùng đạt đến nút 2 trong đó có phiên giao dịch.
Thông điệp phát lại là bản sao của thông điệp ban đầu ngoại trừ việc chúng có khác nhau phát sóng ID Head mà các peer sử dụng để biết đó là một phát sóng khác.
Quản lý tranh chấp
Như đã nói ở trên, máy chủ trạng thái sử dụng mô hình đồng thời bi quan khi truy cập vào mục trạng thái phiên trong từ điển phiên. Hoạt động này tốt bởi vì hầu hết các yêu cầu mất một thời gian ngắn để xử lý. Tuy nhiên, một trong những yêu cầu cụ thể có thể mất một thời gian lâu hơn nữa để xử lý, và có thể dẫn đến thiếu tài nguyên và suy giảm hiệu suất.
GetTransferMessage phát sóng thông điệp được khởi xướng bởi một peer khi nó cần phải làm việc với trạng thái phiên nó không có. Khi phát sóng đạt đến một đẳng với các phiên yêu cầu, trạng thái phiên được chuyển giao cho các peer yêu cầu.
Không giống như các hoạt động khác trên trạng thái phiên, chuyển giao có thể mất một số lượng đáng kể thời gian vì các đồng đẳng có để kết nối với peer khác, có thể xác thực, và truyền tải dữ liệu. Điều quan trọng cần lưu ý rằng bất kỳ yêu cầu từ máy chủ web có thể bắt đầu phát sóng GetTransferMessage.
Trong tiến trình chuyển giao, phiên giao dịch được đánh dấu là "sử dụng" và các yêu cầu khác trong phiên giao dịch đó sẽ phải chờ đợi như bình thường. Tuy nhiên, khi nó mất một thời gian lâu hơn nữa, thread chờ đợi cho hoạt động chuyển giao để hoàn thành tiêu tốn rất nhiều tài nguyên hệ thống. Chúng cũng có thể thời gian chờ nếu việc chuyển giao phải mất quá lâu hoặc nếu phiên làm việc liên tục chuyển xung quanh mạng do thông điệp tràn ngập. Một trường hợp xấu được minh họa dưới đây:
Trong sơ đồ trên, người dùng bị ngập lụt ứng dụng web với các yêu cầu, do đó gây ra các yêu cầu phiên được truyền đến một máy chủ của trạng thái.
Bởi vì tất cả các yêu cầu bắt nguồn từ một người sử dụng, tất cả các yêu cầu phiên tham chiếu cùng id phiên. Cân bằng tải hoặc phân vùng trạng thái phân phối các yêu cầu của các máy chủ trạng thái ba.
Điều quan trọng cần lưu ý là ngay cả khi nó không chắc rằng cân bằng tải hoặc phân vùng trạng thái sẽ phân phối các yêu cầu cho một phiên giữa các máy chủ trạng thái khác nhau, người dùng có thể tạo ra các kịch bản hiển thị ở trên chỉ đơn giản bằng cách nhấn và giữ trình duyệt quan trọng làm mới trên ứng dụng web sử dụng một phân vùng trạng thái kém thực hiện hoặc một cân bằng tải bị hỏng hóc.
Ngoài ra, một nhóm tổ chức người dùng xấu (hoặc một botnet) có thể xuất kịch bản này ngay cả trên đúng chức năng phân chia đĩa trạng thái và cân bằng tải.
Mỗi máy chủ trạng thái có yêu cầu chờ đợi để được xử lý. Nếu phiên giao dịch trong nhu cầu cao, trên máy chủ của trạng thái 3, yêu cầu trên máy chủ đó trạng thái sẽ được xử lý từng cái một cách nhanh chóng.
Máy chủ trạng thái 1 và 2 chương trình phát sóng yêu cầu chuyển giao phiên. Thông điệp cuối cùng đạt đến máy chủ trạng thái 3 và yêu cầu được chuyển giao cho máy chủ trạng thái 2. Những yêu cầu về máy chủ trạng thái 3 mà không được xử lý sẽ đợi cho đến khi chuyển giao hoàn tất.
Sau khi chuyển nhượng phiên máy chủ 2 hoàn thành, yêu cầu trên máy chủ 2 được xử lý, trong khi các yêu cầu trên máy chủ 3 chương trình phát sóng yêu cầu phiên.
Chương trình phát sóng có nguồn gốc từ máy chủ của trạng thái 1 đến máy chủ và trạng thái 2 phiên giao dịch được chuyển đến máy chủ của trạng thái 1. Các máy chủ giữ chuyển giao phiên giao dịch với nhau trong khi hầu hết các yêu cầu chờ đợi, bởi vì ngay cả khi phiên được chuyển giao, máy chủ trạng thái chỉ có thể xử lý một số yêu cầu trước khi nó được chuyển đến một máy chủ của trạng thái.
Để làm cho vấn đề tồi tệ hơn, nếu máy chủ nhà nhận được một GetTransferMessage tin nhắn sau khi nó đã chuyển giao phiên, nó rebroadcasts tin nhắn (như đã giải thích ở trên), dẫn đến nhiều hơn GetTransferMessage chương trình phát sóng trên mạng, dẫn tới thiếu tài nguyên kéo dài.
Quá trình chuyển tương đối chậm và vì tất cả các yêu cầu phải chờ đợi để được xử lý cùng một lúc bởi mỗi máy chủ trạng thái, yêu cầu bắt đầu thời gian ra và máy chủ web bắt đầu yêu cầu loại bỏ. Các máy chủ trạng thái là không biết rằng máy chủ web đã loại bỏ những yêu cầu và vẫn tiến hành để xử lý chúng.
Những yêu cầu cần thiết, chờ đợi đến lượt mình, theo chu kỳ bộ vi xử lý máy chủ có giá trị và làm giảm chất lượng dịch vụ.
Nếu rất nhiều những yêu cầu này đến nơi, chúng sẽ nhanh chóng sử dụng hết tài nguyên bộ xử lý và máy chủ ngừng hẳn lại.
Trong khi nó có thể không thể ngăn chặn bất kỳ nhóm người dùng làm lụt các máy chủ trạng thái với yêu cầu, bảo vệ máy chủ trạng thái đối với các nguyên tắc sau đây: bất kỳ suy thoái của dịch vụ do một phiên tranh chủ yếu ảnh hưởng đến người sử dụng của phiên đó, và đạt được mục tiêu này với các cơ chế sau:
Khi một yêu cầu là phải được xử lý và máy chủ thông báo phiên giao dịch đang được chuyển giao, yêu cầu dừng lại được xử lý và được xếp hàng đợi để được xử lý khi chuyển giao. Điều này ngăn cản các yêu cầu từ lên chu kỳ xử lý trong khi chờ đợi, và giải phóng tài nguyên, do đó yêu cầu khác từ những người dùng khác có thể được xử lý. Nếu số lượng yêu cầu trên một danh sách chờ đợi phiên chuyển quá dài, sau đó tất cả những thông báo sẽ bị loại bỏ bởi vì nó có nghĩa là phiên tranh và máy chủ không phải bận tâm xử lý chúng.
Sau khi chuyển giao hoàn tất và yêu cầu xếp hàng đợi sẵn sàng để được tái sử dụng và máy chủ thông báo rằng cùng phiên là được chuyển một lần nữa bởi yêu cầu, sau đó yêu cầu sẽ bị loại bỏ và không được xử lý, vì nó có nghĩa là phiên không gây tranh chấp.
Trước khi cố gắng yêu cầu để truy vấn mạng (bằng cách phát sóng) cho phiên làm việc, nó sẽ kiểm tra nếu nó được mong đợi câu trả lời từ truy vấn trước cho phiên đó, và yêu cầu được xếp hàng đợi vào danh sách các yêu cầu để được xử lý khi truy vấn được nhận. Điều này làm giảm số lượng GetTransferMessage tin nhắn sẽ được tạo ra trên mạng, do đó làm giảm rebroadcasts không cần thiết và tra cứu. Nếu số lượng yêu cầu trên danh sách chờ đợi quá dài, thì tất cả những yêu cầu đó sẽ bị loại bỏ bởi vì nó có nghĩa là phiên là tranh chấp.
Cuối cùng, tất cả các yêu cầu gửi đến đang xếp hàng trong hàng đợi phiên id cụ thể của chúng và các cuộc thăm dò xử lý thông điệp hàng đợi yêu cầu gửi đến theo cách thức và quy trình vòng tròn, như hình dưới đây:
Điều này có nghĩa rằng tất cả các yêu cầu phiên được đối xử công bằng, không có người sử dụng duy nhất có thể làm gián đoạn đáng kể tốc độ mà thông điệp có nguồn gốc từ những người dùng khác được xử lý. Ngoài ra, nếu hàng đợi cho phiên id đặc biệt là quá dài, hàng đợi được bỏ đi bởi vì nó có nghĩa là phiên là tranh chấp.
Tất cả những kỹ thuật được sử dụng bởi các máy chủ trạng thái chỉ có thể ảnh hưởng xấu đến các ứng dụng web của người sử dụng vi phạm.
Kết luận
Ngang hàng đến máy chủ trạng thái là hoàn toàn tương thích ngược với máy chủ Microsoft trạng thái cung cấp và minh bạch có thể thay thế nó. Máy chủ trạng thái ngang hàng có thể chuyển phiên với nhau, cải thiện độ tin cậy của trạng thái phụ thuộc vào các ứng dụng web phiên. Máy chủ trạng thái ngang hàng cũng hoạt động như một lớp bảo mật để bảo vệ dữ liệu phiên trên mạng.