Java DatagramPacket (UDP) tối đa gửi/recv đệm kích thước

Question

Trong Java khi sử dụng DatagramPacket giả sử bạn có bộ đệm byte[1024*1024]. Nếu bạn chỉ cần vượt qua điều đó cho DatagramPacket khi gửi/nhận sẽ một Java nhận cuộc gọi cho khối DatagramPacket cho đến khi nó đã đọc toàn bộ megabyte?

Tôi hỏi nếu Java sẽ chia nhỏ hoặc chỉ cố gắng gửi toàn bộ nội dung bị xóa.

Thông thường giới hạn kích thước là khoảng 64KB cho gói UDP, nhưng tôi tự hỏi vì API của Java cho phép mảng byte nếu đó là giới hạn và thứ gì đó cực lớn bị bỏ hoặc chia nhỏ và ghép lại cho bạn.

Nếu bỏ cuộc gọi API nào sẽ cho tôi biết tải trọng dữ liệu tối đa mà tôi có thể sử dụng trong cuộc gọi Java? Tôi đã nghe nói rằng IPv6 cũng có khung jumbo, nhưng không DatagramPacket (hoặc DatagramSocket) hỗ trợ rằng kể từ khi UDP xác định spec tiêu đề?

Answer 1

DatagramPacket chỉ là trình bao bọc trên ổ cắm dựa trên UDP, vì vậy các quy tắc UDP thông thường sẽ được áp dụng.

64 kilobyte là kích thước tối đa theo lý thuyết của một gói dữ liệu IP hoàn chỉnh, nhưng chỉ có 576 byte được đảm bảo định tuyến. Trên bất kỳ đường dẫn mạng cụ thể nào, liên kết với Đơn vị truyền tối thiểu nhỏ nhất sẽ xác định giới hạn thực tế. (1500 byte, tiêu đề ít hơn là mức tối đa chung, nhưng không thể dự đoán có bao nhiêu tiêu đề sẽ an toàn nhất để giới hạn thư đến khoảng 1400 byte.)

Nếu bạn vượt quá giới hạn MTU, IPv4 sẽ tự động chia datagram thành các mảnh và reassemble chúng vào cuối, nhưng chỉ lên đến 64 kilobyte và chỉ khi tất cả các mảnh vỡ làm cho nó thông qua. Nếu bất kỳ mảnh nào bị mất, hoặc nếu bất kỳ thiết bị nào quyết định nó không thích các mảnh vỡ, thì toàn bộ gói bị mất.

Như đã lưu ý ở trên, không thể biết trước MTU của đường đi là gì. Có nhiều thuật toán khác nhau để thử nghiệm để tìm hiểu, nhưng nhiều thiết bị không thực hiện đúng cách (hoặc cố tình bỏ qua) các tiêu chuẩn cần thiết để tất cả đều đi xuống để thử và sai. Hoặc bạn chỉ có thể đoán 1400 byte cho mỗi tin nhắn.

Vì lỗi, nếu bạn cố gửi nhiều byte hơn hệ điều hành được định cấu hình để cho phép, bạn sẽ gặp lỗi EMSGSIZE hoặc tương đương. Nếu bạn gửi ít hơn nhưng nhiều hơn mạng cho phép, gói sẽ biến mất.

Answer 2

@ Mihai Danila. Bởi vì tôi không thể thêm nhận xét vào câu trả lời ở trên, đó là lý do tại sao viết vào phần trả lời.

Tiếp tục câu trả lời của bạn về kích thước MTU, trong thực tế của tôi, tôi cố gắng sử dụng NetworkInterface.getMTU()-40 để đặt kích thước bộ đệm là DatagramSocket.setSendBufferSize(). Vì vậy, cố gắng không dựa vào getSendBufferSize() Điều này là để đảm bảo nó phù hợp với các kích thước cửa sổ khác nhau trên các nền tảng khác nhau và được chấp nhận rộng rãi trên ethernet (bỏ qua quay số trong giây lát). Tôi đã không hardcoded nó đến 1460 byte (1500-20-20) vì trên cửa sổ, kích thước MTU là phổ 1500. Tuy nhiên, kích thước cửa sổ của nền tảng cửa sổ riêng là 8192 byte, nhưng tôi tin rằng, bằng cách thiết lập SO_SNDBUF để < MTU, Tôi đang gánh nặng lớp mạng/IP ít hơn và cho tất cả các bước nhảy cho các bộ định tuyến và bộ thu, một số chi phí. Vì vậy, giảm độ trễ trên mạng.

Tương tự, đối với bộ đệm nhận, tôi đang sử dụng tối đa 64K hoặc 65535 byte. Bằng cách này, chương trình của tôi có thể di chuyển trên các nền tảng khác nhau bằng cách sử dụng các kích thước cửa sổ khác nhau.

Bạn có nghĩ rằng âm thanh đó có ổn không? Tôi đã không thực hiện bất kỳ công cụ nào để đo lường bất kỳ sự khác biệt nào nhưng giả định rằng trường hợp của nó dựa trên những gì đang diễn ra ở đó.