Cấu trúc liên kết mạng được đề xuất cho ứng dụng truyền dữ liệu/lệnh nhỏ này?

Question

Chúng tôi đang tập hợp một hệ thống đọc ~ 32 tín hiệu điện áp thông qua một thẻ chuyển đổi tương tự sang số, thực hiện xử lý sơ bộ trên chúng và chuyển kết quả (vẫn tách thành 32 kênh) thành mạng dưới dạng gói UDP, nơi chúng được chọn bởi một máy tính khác và được hiển thị khác nhau (a), (b) tiếp tục xử lý, (c) tìm kiếm các tiêu chí để thay đổi trạng thái của hệ thống chuyển đổi, hoặc (d) một số kết hợp của AC. Đồng thời một quá trình GUI đang chạy trên máy tính đang thực hiện các quy trình sau (máy tính vis), thay đổi trạng thái trong cả máy tính tạo dữ liệu và nhiều tiến trình của máy tính, thông qua các thông báo lệnh UDP.

Tôi mới tham gia lập trình mạng và đang cố gắng chọn một cấu trúc liên kết mạng. Có bất kỳ heuristics (hoặc cuốn sách chương, giấy tờ) về topo mạng cho các ứng dụng tương đối nhỏ hơn cần phải vượt qua dữ liệu, lệnh, và xác nhận lệnh linh hoạt?

chi tiết hệ thống:

• liệu thu thập dữ liệu xảy ra trên một hộp Linux duy nhất. Chỉ cần xử lý dữ liệu, lưu vào đĩa và đẩy vào mạng sử dụng khoảng 25% dung lượng CPU và một lượng bộ nhớ nhỏ. Ít hơn 0,5 Mb/giây dữ liệu vào mạng. Tất cả mã để tạo dữ liệu đều bằng C++.

• Máy linux khác chạy một số quy trình trực quan/xử lý/GUI. GUI điều khiển cả máy mua và các quy trình trên máy tính vis/processing/GUI. Mã này chủ yếu là trong C++, với một vài tiện ích nhỏ trong Python.

• Chúng tôi sẽ viết các ứng dụng khác muốn nghe trên dữ liệu thô, dữ liệu đã xử lý và tất cả các lệnh được truyền xung quanh; các ứng dụng đó cũng sẽ muốn phát hành các lệnh - chúng ta không thể dự đoán có bao nhiêu mô-đun như chúng ta muốn viết, nhưng chúng ta mong đợi 3 hoặc 4 quá trình dữ liệu nặng chuyển đổi tất cả 32 luồng đầu vào thành một đầu ra đơn; cũng như 3 hoặc 4 ứng dụng nhỏ một lần như "trình ghi lệnh". Yêu cầu về mô đun có nghĩa là chúng ta muốn các trình tạo dữ liệu cũ và các tổ chức phát hành lệnh không thể biết được có bao nhiêu người nghe đang ở đó. Chúng tôi cũng muốn các lệnh được người nhận của họ thừa nhận.

• Hai máy được kết nối bằng công tắc và các gói (cả dữ liệu và lệnh và xác nhận) được gửi trong UDP.

Năm khả năng chúng tôi đang nghĩ đến việc:

1. dữ liệu suối, ra lệnh, và lời cảm ơn được nhắm mục tiêu theo số cổng. Bộ tạo dữ liệu gửi các luồng dữ liệu độc lập như các gói UDP đến các số cổng khác nhau bị ràng buộc bởi các quá trình visualizer độc lập trên máy tính trực quan hóa. Mỗi quá trình cũng liên kết một cổng lắng nghe cho các lệnh đến và một cổng khác cho các xác nhận gửi đến các lệnh gửi đi. Tùy chọn này có vẻ tốt vì hạt nhân thực hiện công việc lưu lượng/lọc các gói tin; nhưng xấu vì thật khó để xem các quy trình xử lý nhau như thế nào khi đối mặt với các mô-đun được thêm vào không được đoán trước; nó cũng có vẻ dẫn đến sự bùng nổ của các cảng bị ràng buộc.

2. Luồng dữ liệu được nhắm mục tiêu đến trình hiển thị tương ứng theo số cổng và mỗi quy trình liên kết cổng để nghe lệnh. Nhưng tất cả các nhà phát hành lệnh đều gửi các lệnh của họ đến một tiến trình chuyển tiếp gói tin mà biết các cổng lệnh trong tất cả các tiến trình và chuyển tiếp mỗi lệnh tới tất cả chúng. Lời cảm ơn cũng được gửi đến cổng lệnh phổ quát này và được chuyển tiếp đến tất cả các quy trình.Chúng tôi đóng gói thông tin về mục tiêu dự định của mỗi lệnh và mỗi sự thừa nhận vào các gói lệnh/ack, vì vậy các quá trình tự chúng phải sàng lọc qua tất cả các lệnh/acks để tìm những cái liên quan đến chúng.

3. Quy trình chuyển tiếp gói cũng là mục tiêu của tất cả các gói dữ liệu. Tất cả các gói dữ liệu và tất cả các gói lệnh đều được chuyển tiếp đến 40 quy trình khác nhau. Điều này rõ ràng đặt toàn bộ lưu lượng truy cập nhiều hơn trên mạng con; nó cũng làm sạch sự bùng nổ của các cổng bị ràng buộc.

4. Hai nhà phân phối gói có thể chạy trên máy tính - một chương trình phát lệnh/ack cho tất cả các cổng. Các dữ liệu phát sóng khác chỉ có các cổng có thể muốn dữ liệu.

5. Quy trình trực quan hóa 32 của chúng tôi có thể được đóng gói thành 1 quy trình thu thập dữ liệu cho 32 tín hiệu, giảm đáng kể lưu lượng truy cập bổ sung mà tùy chọn 3 gây ra.

Nếu bạn đã thử nghiệm với việc truyền dữ liệu qua nhiều quy trình trên một số máy nhỏ và có một số nguyên tắc hoặc quy tắc về chiến lược nào mạnh mẽ, tôi rất cảm kích lời khuyên! (yêu cầu làm rõ trong các bức ảnh được chào đón)

Answer 1

Tôi không có đủ đại diện để chuyển câu hỏi này đến programmers.stackexhange.com vì vậy tôi sẽ trả lời câu hỏi ở đây.

Đầu tiên tôi sẽ ném một số công nghệ vào bạn, mỗi thứ bạn cần xem xét.

• Hadoop Khuôn khổ giảm bản đồ. Khả năng lấy một lượng lớn dữ liệu và xử lý nó trên các nút được phân phối.

• Kafka Hệ thống nhắn tin có hiệu suất cực cao. Tôi sẽ đề nghị xem đây là xe buýt nhắn tin của bạn.

• ZooKeeper Hệ thống phân phối cho phép bạn "tìm ra" tất cả các khía cạnh khác nhau của hệ thống phân phối của bạn. Đó là một hệ thống phối hợp được phân phối

• Pub/Sub Messaging

• ∅mq Một thư viện socket cho phép pub/sub nhắn tin và sắp xếp thông qua khác N-to-N.

Bây giờ tôi đã ném một vài công nghệ vào bạn, tôi sẽ giải thích những gì tôi sẽ làm.

Tạo hệ thống cho phép bạn tạo N trình kết nối. Các đầu nối này có thể xử lý Dữ liệu/Lệnh N trong sơ đồ của bạn, trong đó N là một tín hiệu cụ thể. Có nghĩa là nếu bạn có 32 tín hiệu, bạn có thể thiết lập hệ thống của mình với 32 đầu nối để "kết nối". Các đầu nối này có thể xử lý các liên lạc hai chiều. Do đó bạn nhận được/lệnh vấn đề. Một trình kết nối sẽ xuất bản dữ liệu của nó tới một thứ gì đó như Kafka trên một chủ đề cụ thể cho tín hiệu đó.

Sử dụng hệ thống xuất bản/đăng ký. Về cơ bản những gì xảy ra là các kết nối xuất bản nó là kết quả cho một chủ đề cụ thể. Chủ đề này là thứ bạn chọn. Sau đó, bộ xử lý, giao diện người dùng, logic nghiệp vụ, v.v. lắng nghe về một chủ đề cụ thể. Đây là tất cả tùy ý và bạn có thể thiết lập chúng tuy nhiên bạn muốn.

============   =============  =====  ============  ============= 
= Signal 1= < --- > = Connector = < -- = K = --> = "signal 1" ---> = Processor = 
============   =============  = a =  ============  ============= 
             = f = 
============   =============  = k =  ============  ============= 
= Signal 2= < --- > = Connector = < -- = a = --> = "signal 2" ---> = Processor = 
============   =============  = =  ============ | ============= 
             = =     | 
============   =============  = =  ============ | 
= Signal 3= < --- > = Connector = < -- = = --> = "signal 3" --- 
============   =============  =====  ============  

Trong ví dụ này, trình kết nối đầu tiên "xuất bản" kết quả là chủ đề "tín hiệu 1" trong đó bộ xử lý đầu tiên đang lắng nghe chủ đề đó. Mọi dữ liệu được gửi đến chủ đề đó sẽ được gửi đến bộ xử lý đầu tiên. Bộ xử lý thứ hai đang lắng nghe cả dữ liệu "tín hiệu 2" và "tín hiệu 3". Điều này đại diện cho một cái gì đó giống như một giao diện người dùng lấy tín hiệu khác nhau cùng một lúc.

Một điều cần lưu ý là điều này có thể xảy ra trên bất kỳ chủ đề nào bạn chọn. Một "bộ vi xử lý" có thể nghe tất cả các chủ đề nếu bạn cho rằng nó quan trọng.