Điểm:3

Chỉ một ổ cắm TCP (thông qua nc) có thể gửi dữ liệu đến cùng một máy chủ/cổng cùng một lúc

lá cờ in

Repro đơn giản - trong một cửa sổ xem các quy trình ở trên cùng, trong lần chạy khác: nc -lkp 10000 > /dev/null & ( head -50000000 /dev/urandom | nc -N 127.0.0.1 10000 ) & ( head -50000000 /dev/urandom | nc -N 127.0.0.1 10000 )

Quan sát rằng chỉ có một cái đầunc quá trình đang tích cực sử dụng CPU.

Gắn dấu vết vào cái đầu cái đó không hoạt động - hãy xem nó bị đình trệ khi ghi, ví dụ:

strace: Quy trình 589084 đính kèm
write(1, "\264\347\270\26\27\24'BRb^\353\302\36@\216\17V\210*n\252`\353\330\351\276\2\250 \330\350\217"..., 4096^Cstrace: Quá trình 589084 đã tách ra
 <tách ra ...>

Thiết lập hai trình nghe trên các cổng khác nhau - ví dụ: 10000 và 10001, và cả hai đều chạy hết tốc lực.

Đây là một ví dụ đơn giản, nhưng tôi có thể sao chép nó bằng các đầu vào và đầu ra khác - ví dụ: zcatting các tệp lớn và gửi chúng đến các dịch vụ sản xuất qua mạng. Nó không liên quan đến đầu vào và nó không liên quan đến ổ cắm nghe.

Vậy - tại sao tôi chỉ có thể có một kết nối tcp tới bất kỳ Máy chủ/cổng cụ thể nào đang chủ động gửi dữ liệu?

Có một nguồn dữ liệu độc lập (vui lòng thử nghiệm nếu bạn không tin tôi) và một quy trình độc lập mở kết nối tcp của chính nó (netstat sẽ hiển thị cả hai đều mở) - điểm chung duy nhất là điểm đến (không nhất thiết phải là nc nghe trên lo - xảy ra với bất cứ điều gì).

Do đích chắc chắn có thể có nhiều ổ cắm đến nhận dữ liệu cùng một lúc và nguồn chắc chắn có thể gửi dữ liệu xuống nhiều ổ cắm mạng cùng một lúc, tôi đang cố gắng tìm ra nguồn gốc của sự tranh chấp, khiến chỉ có một đường ống hoạt động tại Một lần.

Ron Maupin avatar
lá cờ us
Một cổng chỉ có thể được yêu cầu bởi một quá trình duy nhất. Bạn cần cho phép ứng dụng sử dụng các cổng tạm thời cho nguồn (cổng `0`), trong đó các cổng nguồn được chọn "ngẫu nhiên" cho mỗi quy trình. Một kết nối TCP được xác định bởi địa chỉ nguồn và đích cũng như cổng nguồn và đích. Nếu bạn sử dụng cùng một giá trị cho cả bốn, thì theo định nghĩa, đó là cùng một kết nối và việc cố gắng chạy một quy trình mới trên cùng một kết nối sẽ gây ra lỗi.
garethhumphriesgkc avatar
lá cờ in
Có các cổng nguồn khác nhau được sử dụng bởi mỗi kết nối. Đó là cách nc hoạt động theo mặc định, phiên bản thứ hai sẽ không mở nếu cổng nguồn đã được sử dụng và bạn có thể thấy trong đầu ra netstat rằng chúng khác nhau. Tôi đảm bảo với bạn, chúng là hai kết nối TCP khác nhau - tôi khuyến khích bạn nên tự mình thử và xem.
Điểm:8
lá cờ cl
A.B

Tuyên bố miễn trừ trách nhiệm: có rất nhiều nc biến thể. Giả sử từ -k rằng đó là biến thể OpenBSD. Mỗi nc biến thể có đặc quyền riêng của mình.

nc là công cụ sai cho công việc này: nc -lkp 10000 sẽ quản lý một kết nối cùng một lúc, bởi vì nó không rẽ nhánh và mặc dù sử dụng thăm dò ý kiến(2) không bao giờ sử dụng chấp nhận(2) trên kết nối đến thứ 2 cho đến khi quá trình xử lý của kết nối đầu tiên kết thúc: đảm bảo rằng kết nối thứ 2 sẽ không được xử lý. Nếu có thêm một vài người nữa, họ sẽ bắt đầu ở lại SYN-SENT trạng thái vì nc -lkp 10000 sử dụng 1 như lắng nghe(2) tồn đọng: đây không phải là một sự lựa chọn ngẫu nhiên. Điều này có thể được kiểm tra bằng cách sử dụng bước đi trên đường chạy nc -lkp 10000 tiến trình.

Các tài liệu về -k tùy chọn nói như vậy:

-k

Khi kết nối hoàn tất, lắng nghe một số khác. Đòi hỏi -l.
[...]

cách nó được viết không có nghĩa là hai kết nối sẽ được chấp nhận cùng một lúc: chỉ một kết nối sau kết nối trước đó.


thay the nghe mạng lưới với socat (-d -d Để biết thêm thông tin chi tiết):

socat -d -d tcp4-listen:10000,reuseaddr,fork/dev/null

Các cái nĩa tùy chọn đảm bảo xử lý song song dễ dàng: một quy trình cho mỗi kết nối.

garethhumphriesgkc avatar
lá cờ in
Cảm ơn về mẹo - socat hoạt động như mong đợi. Bây giờ tôi phải làm việc tại sao java không - nghe có vẻ giống như một bài đăng stackoverflow.
A.B avatar
lá cờ cl
A.B
Cố gắng nhiều hơn. những cái đầu tiên được hệ điều hành "tự động kết nối". Thông thường đó là tùy thuộc vào công việc tồn đọng nhưng có thể có một số công việc khác. Ở đây, thứ 4 (tức là thứ 3 chưa được xử lý) nhận được SYN-SENT đầu tiên (với `ss -tn dst == 127.0.0.1:10000`)
garethhumphriesgkc avatar
lá cờ in
Xin lỗi A.B - Tôi đã xóa nhận xét của mình sau khi tôi thấy bạn đã sửa đổi câu trả lời của mình để giải quyết vấn đề đó, nhưng trước khi thấy phản hồi của bạn. Đối với những người đến sau, tôi chỉ đề cập rằng các kết nối tiếp theo đã được thiết lập đầy đủ, không phải trong SYN_SENT.
A.B avatar
lá cờ cl
A.B
Tôi đang nói về các kết nối đang chờ xử lý: những nc đang chờ xử lý. Có ít nhất 4 ứng dụng khách nc chạy cùng lúc (trước khi ứng dụng thứ nhất trong số 4 ứng dụng này kết thúc) để thấy điều này. Hành vi chính xác có thể phụ thuộc vào phiên bản kernel và cài đặt của nó, chỉ cần thử thêm. Ví dụ của bạn trong OP chỉ chạy hai máy khách nên hành vi này sẽ không được nhìn thấy.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.