Tôi đang cố gắng gửi tin nhắn qua netcat. Sau khi gửi tin nhắn, netcatphải chấm dứt.

Tôi đã thử như sau:

cat tsmmessage.bin | nc -u localhost 4300
nc -u localhost 4300 < message.bin

Các -qquốc gia lựa chọn:

-q giây

sau EOF trên stdin, đợi số giây đã chỉ định rồi thoát. Nếu giây là âm, chờ mãi.

Nhưng

nc -q0 -u localhost 4300 < message.bin

cũng không hoạt động.

Tôi đang thiếu gì?

Giả sử rằng sau khi gửi kết nối EOF sẽ không hoạt động, bạn có thể sử dụng -w timeouttùy chọn, hoạt động với giá trị timeoutbằng 0 (không giống như -qtùy chọn ngu ngốc ...)

cat tsmmessage.bin | nc -u localhost 4300 -w0

Nếu không có -qcờ, ví dụ của netcatbạn sẽ đợi mãi. Không có thông báo "kết thúc luồng" với UDP, vì vậy không có cách nào netcatđể biết rằng cả stdin và kết nối mạng đã kết thúc.

Ví dụ: sử dụng TCP / IP, công việc này như mong đợi:

nc -l localhost 4300                     # Window 1
nc localhost 4300 </etc/group            # Window 2

Nhưng như bạn đã xác định, sử dụng UDP / IP, điều này không bao giờ kết thúc:

nc -u -l localhost 4300                  # Window 1
nc -u localhost 4300 </etc/group         # Window 2

Đây là nơi -qcờ đến. Nhưng thật không may, nó không chấp nhận giá trị của 0. Nó cũng sẽ không chấp nhận các giá trị không nguyên. Đây là giải pháp thay thế tốt nhất tôi có thể cung cấp mà không cần nhờ đến timeouthoặc một số tiện ích bên ngoài khác:

nc -u -l localhost 4300                  # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2

Ngay cả ở đây, không thể có netcatthời gian lắng nghe một cách duyên dáng. ( -wTùy chọn hết thời gian bị bỏ qua và -qkhông liên quan.) Một cái gì đó như thế này có thể được sử dụng trong một tình huống thực tế, để nó netcatbị giết sau 90 giây:

timeout 90 nc -u -l localhost 4300       # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2

Tình cờ gặp phải vấn đề này khi Googling liên quan đến khá nhiều vấn đề tương tự. Hóa ra vấn đề là netcat đã bị giết bởi bash ngay sau khi tất cả dữ liệu bị hút vào, mà không có bất kỳ cơ hội nào để nhận được phản hồi.

Giải pháp của tôi cho vấn đề này là thêm một số độ trễ sau khi truyền dữ liệu, như thế này:

(echo INFO; sleep 1) | nc redis.service.consul 6379

Với một tập tin này có thể trông như:

(cat tsmmessage.bin; sleep 5) | nc -u localhost 4300

udp

# listen on receiver
nc -u -l localhost -p 4300

# sender
cat tsmmessage.bin | nc -u -N -q 0 localhost 4300

tcp

# listen on receiver
nc -l localhost -p 4300

# sender
cat tsmmessage.bin | nc -N localhost 4300