TIÊu chuẩn việt nam tcvn 11777-9: 2017 with amendment 5: 2014

Hồ sơ đầy đủ cung cấp khả năng vượt ngoài các hồ sơ mức thấp hơn theo quy định tại tiêu chuẩn này

Thử nghiêm khả năng tương tác JPIP được thực hiện tại mức ngăn, chẳng hạn trong dữ liệu truyền từ máy chủ tới máy khách. Điều này cung cấp tập ảnh mẫu và yêu cầu JPIP mẫu theo tiêu chuẩn ISO / IEC 15444-1, cùng các với các tiêu đề và dữ liệu đáp ứng mẫu tương thích từ máy chủ. Dữ liệu đáp ứng từ máy chủ dưới dạng tập tin JPP và tập tin JPT, được mô tả trong Điều A.5.

Tất cả các dòng mẫu được tạo ra với tham chiếu máy khách conciseness-pref thiết lập là "concise" và view-window-pref thiết lập là "fullwindow". Nguồn tài nguyên hạn chế tại máy chủ có thể yêu cầu máy chủ thực tế thực hiện để hạn chế yêu cầu đòi hỏi quá nhiều dữ liệu từ máy chủ cùng một lúc. Các dữ liệu mẫu được cung cấp trong điều này không kích hoạt các điều kiện như vậy cho việc triển khai nhắm đánh địa chỉ cho máy bàn state-of-the-art. Nếu máy chủ thực hiện bao gồm các phương thức để hạn chế yêu cầu để hạn chế nguồn tài nguyên cần thiết để thực hiện kiểm thử, loại này phải được vô hiệu hóa đối với mục đích đo kiểm tuân thủ. Điều này không giới thiệu giới hạn nguồn tài nguyên mà máy chủ phải có khả năng hoạt động.

Thử nghiệm máy chủ là việc kết hợp biến thể và hồ sơ cho trước. Thử nghiệm một máy chủ JPIP được thực hiện bằng cách khởi tạo yêu cầu JPIP cho dữ liệu từ ảnh mẫu và so sánh các dữ liệu lấy từ các máy chủ trong thử nghiệm với những đáp ứng mẫu theo các biến thể và hồ sơ sử dụng thuật toán được mô tả trong Điều J.4.3. Để khẳng định sự phù hợp với hồ sơ và biến thể cụ thể, máy chủ sẽ vượt qua tất cả các bài đo kiểm máy chủ đối với hồ sơ này và tất cả các hồ sơ mức thấp hơn bằng cách sử dụng biến thể quy định.

Mặc dù các máy chủ JPIP được phép thay đổi những gì chúng cung cấp, các dòng mẫu sẽ không được sửa đổi bởi máy chủ trong quá trình thử nghiệm.

CHÚ THÍCH 1: Các dòng mẫu cho kiểu trả về ảnh JPP được tạo ra theo cách mà mỗi phân khu ảnh của dòng mẫu chỉ bao gồm một khối mã trong mỗi băng con. Vì vậy không cần thiết quá trình chuyển mã bất kỳ, mặc dù cho phép chèn thêm hoặc loại bỏ các nhãn COM, PLT, PLM và TLM trong ngữ cảnh của thủ tục đo kiểm này.

Đối với mục đích thử nghiệm, dữ liệu JPIP mà máy chủ sẽ gửi qua mạng phải được lưu lại dưới định dạng tập tin JPP hoặc tập tin JPT thích hợp. Bất kỳ một đóng gói nào như các mã đáp ứng HTTP phải bị loại bỏ khỏi những tập tin này.

Các mã EOR chỉ định các thông tin phải nằm trong trong các tập tin. Nội dung của những tập tin này sau đó được so sánh với nội dung của các đáp ứng mẫu. Đáp ứng được trả về bởi máy chủ phù hợp, tuy nhiên, khác với đáp ứng mẫu.

CHÚ THÍCH 2: Trên thủ tục đo kiểm quy định tại Điều l.4.3, cho phép sự khác biệt so với các dòng mẫu như sau:

- Sắp xếp lại các ngăn dữ liệu trong đáp ứng.

- Đặt lại các nội dung của các khung dữ liệu đặc tả vào khung Chờ.

- Sử dụng quá trình mã hóa tương đương với các tiêu đề VBAS của ngăn dữ liệu.

- Sử dụng các phương pháp phân nhỏ dữ liệu đặc tả vào các ngăn chờ, cung cấp các dữ liệu đặc tả yêu cầu nằm trong các đáp ứng.

- Sử dụng biểu diễn tương đương dòng cho dữ liệu đặc tả.

Khái niệm quy định sự khác nhau giữa các dòng có thể chấp nhận được mặc nhiên được đưa ra bởi các thủ tục đo kiểm trong Điều J.4.3.

CHÚ THÍCH 3: Công cụ đo kiểm ("vbasdiff.py") được cung cấp để thực hiện, thủ tục đo kiểm và phân tích sự khác biệt giữa hai đáp ứng máy chủ.

CHÚ THÍCH 4: Các máy chủ có thể cung cấp thêm các biểu diễn tương đương dòng. Tuy nhiên, việc xác định tính đúng đắn của chủng nằm ngoài phạm vi của phụ lục này; chúng được bỏ qua trong phương pháp luận thử nghiệm quy định tại Điều I.4. Hơn nữa, đo kiểm tuân thủ đối với JPlP áp dụng cho dữ liệu đòi hỏi phải các giá trị cờ của khung chờ khác, ví dụ như sử dụng trong tiêu chuẩn ISO / IEC 15444-3, nằm ngoài phạm vi của phụ lục

J.4.3 Đáp ứng máy chủ So sánh

Điều này xác định một thuật toán quy định so sánh các dữ liệu đáp ứng của máy chủ trong thử nghiệm với những đáp ứng mẫu được cung cấp bởi tiêu chuẩn này.

CHÚ THÍCH: Bao gồm tập dòng thử nghiệm là một tập lệnh thử nghiệm python ("vbasdiff.py") để thực hiện so sánh triển khai giải thuật được mô tả sau đây: Bản chất của thử nghiệm phụ thuộc vào sự tồn tại của trường độ dài. Nếu trường len có mặt trong yêu cầu, chỉ thử nghiệm với kích thước đáp ứng máy chủ và mã EOR. Nếu không, thực hiện bốn bước sau đây:

1) Phân tích cú pháp các bản tin trong tập tin jpp hoặc jpt, kiểm tra quá trình mã hóa và gán chúng vào các ngăn.

2) Đưa các ngăn dữ liệu đặc tả vào dạng chính tắc theo quy định tại Điều J.4.3.3.

3) Đo lượng dữ liệu dư thừa.

4) So sánh các phần của dữ liệu dư thừa với một ngưỡng.

J.4.3.1 So sánh kích thước đáp ứng máy chủ

Trong trường hợp yêu cầu bao gồm trường len, so sánh độ dài tính bằng byte của đáp ứng máy chủ không bao gồm bản tin EOR bất kỳ với độ dài yêu cầu. Nếu theo kích thước tính bằng byte của đầu ra này là lớn hơn độ dài yêu cầu, so sánh bị lỗi. Nếu không có dữ liệu (ngoại trừ EOR) bị trả về, so sánh bị lỗi. Thì so sánh các mã EOR của dòng thử nghiệm với mã EOR của dòng mẫu. Nếu mã EOR của dòng thử nghiệm không phải là 1 ("Image Done") cũng không phải là 2 ("Window Done"), xem Bảng D.2) cũng không bằng mã EOR của dòng mẫu, so sánh bị lỗi. Nội dung bản tin EOR sẽ bị bỏ qua.

CHÚ THÍCH: Các dòng mẫu chứa các yêu cầu tương tự có và không có trường len.

J.4.3.2 Bước phân tích cú pháp

Đối với yêu cầu kiểm tra không bao gồm trường len, dữ liệu thử nghiệm và mẫu được phân tích. Các tiêu đề bản tin VBAS phải được giải mã, ban đầu tách bản tin EOR từ các bản tin thông thường, và đối với các bản tin thông thường, nhận diện định danh lớp trong, lớp bản tin, số thứ tự dòng mã (CSN), "bit bản tin cuối cùng" (bit 4, dán nhãn Để"c" trong Hình A.3), giá trị AUX, nếu có, độ lệch và độ dài bản tin. Sau đó nội dung bản tin sẽ được đưa vào ngăn dữ liệu tùy theo trường độ lệch và độ dài bản tin trong tiêu đề bản tin, trong đó mỗi ngăn được xác định bởi bộ ba tham số lớp ngăn, định danh lớp trong và số thứ tự dòng mã. Ánh xạ giữa lớp bản tin và lớp ngăn được đưa ra trong Bảng A.2, Phụ lục A. Nó sẽ được chấp nhận nếu bản tin thay thế phần dữ liệu cung cấp bởi bản tin cũ, nhưng nó không được chấp nhận cung cấp dữ liệu cho làm phình to ngăn xếp khi bản tin cuối cùng đã nhận được.

Đầu tiên, các mã EOR được so sánh. Nếu mã EOR của dòng thử nghiệm không phải là 1 ("Image Done") mà cũng không phải là 2 ("Window Done", xem Bảng D.2) cũng không bằng mã EOR của dòng mẫu, so sánh bị lỗi. Phần thân của bản tin EOR bị bỏ qua.

Giá trị AUX hoặc được bao gồm trong tất cả các bản tin tập trung trong ngăn dữ liệu, hoặc không có. Nếu không, các tập tin bị hỏng và so sánh bị lỗi. Đối với mỗi ngăn dữ liệu có chứa các bản tin với các giá trị AUX, các giải thuật sau đây được sử dụng để chỉ định một giá trị AUX cho ngăn dữ liệu:

- Đối với ngăn dữ liệu phân khu ảnh, giá trị AUX của ngăn phải là giá trị AUX lớn nhất được tìm thấy trong tất cả các bản tin tập trung trong ngăn.

- Đối với ngăn dữ liệu khối ảnh, giá trị AUX của ngăn phải là giá trị AUX nhỏ nhất được tìm thấy trong tất cả các bản tin tập trung trong ngăn.

Chú thích: Bản tin chứa các giá trị AUX không xuất hiện trong thử nghiệm với hồ sơ 0 và 1.

J.4.3.3 Tóm tắt cách bố trí ngăn dữ liệu đặc tả

Trong bước tiếp theo, ngăn dữ liệu đặc tả được đưa vào dưới dạng chính tắc để tóm tắt một cách máy chủ cụ thể chia nhỏ dữ liệu đặc tả thành các khung Chờ. Các bản tin tập trung trong ngăn dữ liệu có thể không chỉ ra tất cả dữ liệu của nó, điều này xảy ra với bản tin ngăn dữ liệu được định từng phần và chấp nhận các ngăn dữ liệu đặc tả bao gồm "holes" của dữ liệu bị mất được định vị lại theo cơ chế khung chờ. Các vùng như vậy được gọi là "missing bytes" như sau.

Các tập lệnh kiểm tra thực hiện các thuật toán sau đây để tái tạo lại dữ liệu trung gian từ tập tin jpp hoặc jpt:

- Ngăn dữ liệu đặc tả # 0 được quét trong dòng kiểm tra đối với tiêu đề khung không đầy đủ. Các dòng thử nghiệm và mẫu thực hiện so sánh bằng cách đánh dấu các phạm vi tương ứng với dữ liệu bị mất trong cả hai dòng. Các dòng sửa đổi kiểm tra các khung Chờ. Nếu các giá trị cờ của khung chờ có tập LSB, chỉ ra rằng OriglD hợp lệ, khung chờ sẽ được xử lý như trong các bước tiếp theo; nếu không, nó sẽ vẫn nguyên bản:

• Nếu ngăn dữ liệu tham chiếu bởi khung chờ nằm trong dòng, thì khung sẽ được thay thế bằng tiêu đề khung và nội dung ngăn tham chiếu bên trong.

• Nếu ngăn dữ liệu tham chiếu, trong khung chờ không nằm trong dòng, khung chờ sẽ được gỡ bỏ, tiêu đề khung trong khung chờ sẽ được chèn vào trong dòng, và trong dãy byte trong ngăn địa chỉ bị mất sẽ được đánh dấu là dữ liệu bị mất.

- Sau khi ngăn dữ liệu đặc tả # 0 của dòng thử nghiệm và mẫu đã được phân tích như trên, tất cả các ngăn dữ liệu đặc tả khác ngăn # 0 còn lại được lấy ra khỏi dòng.

CHÚ THÍCH: Các thuật toán trên yêu cầu các phần mềm thực hiện so sánh chứa cơ sở dữ liệu mô tả các khung là siêu khung và là các khung đơn giản. Điều này cần thiết để có thể quét nội dung siêu khung một cách chính xác đối với các khung chờ. Trong quá trình kiểm tra, đó là lợi thế không bao gồm dữ liệu dư thừa trong các đáp ứng. Các máy chủ nên sử dụng khung chờ phù hợp để tránh dữ liệu dư thừa. Đối với hồ sơ 1 và cao hơn, mọi siêu khung được thay thế bằng một khung chờ trong dòng mẫu. Dòng mẫu đối với hồ sơ 0 được tạo ra mà không cần khung chờ và chỉ có số lượng dữ liệu đặc tả tối thiểu, theo quy định tại Điều C.5, sẽ được đưa ra.

Trong bước thứ ba, tất cả ngăn dữ liệu còn lại phải được so sánh, định vị cho mỗi giá trị bin-class, bin-Id và CSn trong một dòng tương ứng ngăn trong dòng thứ hai: một ngăn dữ liệu có mặt trong dòng thử nghiệm khi và chỉ khi nó có mặt trong dòng mẫu; nếu không, so sánh bị lỗi.

Các ngăn dữ liệu được so sánh như sau:

- Nếu một trong số các ngăn dữ liệu mang giá trị AUX, thì các ngăn cũng khác phải mang giá trị AUX. Nếu cả hai ngăn mang giá trị AUX, thì chúng phải bằng nhau; nếu không, so sánh bị lỗi. Xem I.4.3.1 về cách tính toán giá trị AUX của một ngăn từ giá trị AUX trong các bản tin tập trung trong ngăn.

- Nếu ngăn dữ liệu mẫu chứa bản tin chỉ ra rằng byte "cuối cùng" của ngăn đã được kết hợp, các ngăn dữ liệu tương ứng trong dòng đang thử nghiệm cũng phải chứa một bản tin với cùng chỉ mục. Nếu không, việc so sánh bị lỗi.

- Đối với tất cả các loại ngăn ngoại trừ ngăn dữ liệu tiêu đề chính và ngăn dữ liệu tiêu đề khối ảnh, tất cả các byte được định nghĩa trong ngăn dữ liệu được so sánh phải bằng nhau. Nếu không, việc so sánh bị lỗi. Số byte dư thừa trong dòng thử nghiệm nhưng không phải trong trong dòng mẫu sẽ được gộp lại.

- Các ngăn dữ liệu tiêu đề chính và ngăn dữ liệu tiêu đề khối ảnh được so sánh bằng cách phân tích chúng thành các đoạn nhãn và so sánh các đoạn nhãn độc lập theo thứ tự. Tất cả các đoạn nhãn ngoại trừ COM, PLT, PLM và TLM phải bằng nhau.

Sau khi so sánh tất cả ngăn dữ liệu, lượng byte dư thừa Ne đo được trong bước ba này sẽ được chia cho tổng số byte trong các ngăn Nt. Nếu thương số này cao hơn ngưỡng T, so sánh bị lỗi. Đối với yêu cầu mẫu và mẫu đáp ứng hiện có đang được xác định trong tiêu chuẩn này, ngưỡng T bằng không.

CHÚ THÍCH: Để kiểm tra tuân thủ của các máy chủ theo quy định tại phụ lục này, các máy chủ sẽ hoạt động phù hợp với các điều ngắn gọn về các trường pref, xem C.10.2.8. Các máy chủ không hoạt động theo cách này vẫn có thể được tuân thủ theo tiêu chuẩn này, nhưng thử nghiệm của chúng là nằm ngoài phạm vi của phụ lục này.

J.4.4 Thử nghiệm máy khách

Thử nghiệm máy khách cụ thể cho một biến thể cho trước. Tuân thủ của các máy khách sẽ được kiểm tra bằng cách cung cấp một tiêu đề đáp ứng mẫu và tập tin jpp hoặc jpt cho biến thể và hồ sơ cụ thể để tiến thành đo thử nghiệm. Máy khách xử lý đáp ứng này. Đối với mục đích của thử nghiệm, máy khách sẽ tạo ra các tập tin hoặc dòng mã tương thích với tiêu chuẩn ISO / IEC 15444-1. Tính năng này không yêu cầu bắt buộc đối với một máy khách phải tuân thủ, nhưng nó được yêu cầu để thực hiện thử nghiệm. Việc tạo ra các dòng mã hoặc tập tin sẽ được so sánh với dòng mã hoặc tập tin mẫu được cung cấp tại điều này bằng cách sử dụng thuật toán xác định sau đây. Để khẳng định sự phù hợp với biến thể, máy khách phải vượt qua tất cả các bài đo kiểm đối với biến thể nhất định.

So sánh các dòng mẫu với các dòng được tạo ra bởi máy khách được thực hiện trong hai giai đoạn: ban đầu so sánh dữ liệu đặc tả (nếu nó) hiện có, sau đó so sánh các dữ liệu hình ảnh có sẵn.

CHÚ THÍCH: Thủ tục kiểm tra máy khách được mô tả ở đây chỉ để kiểm tra khả năng của máy khách phân tích thành công các dòng JPP hoặc JPT, và tái tạo tập tin phù hợp JPEG 2000 hoặc dòng mã từ dữ liệu đó. Nó không kiểm tra khả năng của máy khách tạo ra các yêu cầu hoặc khai thác các khả năng khác được cung cấp trong tiêu chuẩn này.

Nếu địa chỉ được được mã hóa trong định dạng tập tin JPEG 2000, các nội dung của khung tập tin mẫu và nội dung của các khung ngoại trừ khung dòng mã được tạo ra bởi thử nghiệm được so sánh. Tuy nhiên máy khách cho phép thực hiện các sửa đổi sau đây:

- Chứa các khung UUID bổ sung không có mặt trong dòng mẫu.

- Sắp xếp lại các khung, cung cấp các khung không làm thay đổi ngữ nghĩa của tập tin.

Bao gồm các sửa đổi, nội dung khung của dòng thử nghiệm và dòng mẫu phải giống hệt nhau. Nếu không, việc so sánh bị lỗi.

J.4.4.2 So sánh dữ liệu ảnh phục dựng

Nếu yêu cầu được sử dụng để tạo ra tập tin jpp hoặc jpt mẫu bao gồm trường yêu cầu đối với cửa sổ hiển thị không rỗng, các dữ liệu ảnh phục dựng lại phải được so sánh. Các dòng và dòng mã mẫu tạo ra bởi máy khách thực hiện đều được giải mã bởi bộ giải mã thích hợp JPEG 2000. Việc thực hiện tương tự được sử dụng cho cả hai dòng. Ảnh kết quả phải giống hệt nhau đến từng điểm ảnh trong cửa sổ hiển thị của yêu cầu. So sánh trong giai đoạn này được thực hiện như sau:

- Đặt fx '= Xsiz-XOsiz và fy' = Ysiz-YOsiz trong đó Xsiz, XOsiz và Ysiz, YOsiz được lấy từ các nhãn Siz của dòng mã có liên quan.

- Đặt ox, oy và sx, sy cho độ lệch và kích thước vùng của cửa sổ hiện thị được xác định trong yêu cầu, và đặt fx và fy là kích thước khung được xác định trong yêu cầu.

; ; ;

(J-1)

CHÚ THÍCH 1: Các thủ tục trên giống nhau, nhưng không giống với định nghĩa trong Công thức (C-1) và (C-2) Điều C.4. Sự khác biệt mức phân giải r trong công thức (C-1) ở đây được hạn chế bằng không, tuân theo sự so sánh tại độ phản giải ảnh đầy đủ.

CHÚ THÍCH 2: Công cụ ("jp2file.py") được cung cấp trong tập tin điện tử đính kèm với tiêu chuẩn này mà tạo ra một văn bản đại diện cho nội dung của các tập tin JPEG 2000 hoặc dòng mã để dễ dàng phân tích các dữ liệu được tạo ra bởi các máy khách.

CHÚ THÍCH 3: Toàn bộ thủ tục kiểm tra các máy khách yêu cầu nhà cung cấp để triển khai bộ giải mã tương thích JPEG 2000, tuy nhiên, không cần phù hợp với tiêu chuẩn này. Khả năng máy khách tạo ra tập tin JPEG 2000 hoặc dòng mã cũng không bắt buộc phải tuân thủ tiêu chuẩn này 9 nhưng được yêu cầu để thực hiện các bài kiểm tra trong phụ lục này.

(Quy định)

Sử dụng JPIP với các yêu cầu HTTP và các khai báo UDP

K.1 Tổng quan

Phụ lục này cung cấp các chi tiết về truyền tải "http-udp", được xác định trong tài liệu này như HTTP-UDP. Truyền tải HTTP-UDP sử dụng các cơ chế tương tự như việc truyền tải HTTP để gửi yêu cầu máy khách đến máy chủ và nhận được các tiêu đề đáp ứng và mã trạng thái của máy chủ. Tuy nhiên, dữ liệu đáp ứng của máy chủ được phân phối như là các gói tin UDP qua một kết nối UDP bổ trợ. Thông tin truyền tải trên kết nối UDP bổ trợ này được nhận diện phải được truyền đi như toàn bộ đáp ứng thuần HTTP, ngoại trừ việc nó được đóng khung thành nhiều khúc dữ liệu, mỗi khúc trong số đó có số thứ tự khúc dữ liệu và bản ghi của request-id kết hợp với các yêu cầu của máy khách tương ứng. Mỗi khúc dữ liệu phải chứa một số bản tin JPIP và tối đa một bản tin EOR như quy định tại Phụ lục A. Định dạng lớp bản tin và số thứ tự dòng mã phải xuất hiện ít nhất trong bản tin JPIP đầu tiên của mỗi khúc dữ liệu.

CHÚ THÍCH: Do truyền tải UDP không tin cậy (nghĩa là, các gói tin UDP có thể bị mất hoặc đến không theo thứ tự) máy khách có thể không nhận được tất cả khúc dữ liệu tương ứng với yêu cầu. Máy khách có thể sử dụng trường yêu cầu Bỏ qua dạng tường minh để thông báo cho máy chủ về tình trạng này, xem C.7.6.

K.2 Yêu cầu máy khách

Các yêu cầu được phân phối trên các kênh chính như các yêu cầu HTTP. Chúng có tính chính xác giống như các yêu cầu được phát hành qua kênh có sử dụng truyền tải HTTP được mô tả trong Phụ lục F. Cụ thể, cả hai yêu cầu HTTP "GET" và "POST" có thể được sử dụng. Yêu cầu máy khách được phát trên kênh JPIP sử dụng truyền tải HTTP-UDP bao gồm trường yêu cầu Request-id (qid).

CHÚ THÍCH: Các máy khách cần phát các giá trị Request-id liên tiếp.

K.3 Cung cấp dữ liệu đáp ứng và thiết lập kênh

Một kênh mới có thể được thành lập cho máy chủ JPIP bằng cách phát một yêu cầu bao gồm các trường yêu cầu Kênh Mới (xem C.3.3). Đối với một mẫu, yêu cầu như vậy có thể được phát bằng cách sử dụng HTTP, mặc dù nó cũng có thể được phát cho một máy chủ JPIP cụ thể sử dụng cơ chế truyền tải bất kỳ phù hợp. Nếu đáp ứng của máy chủ (thông qua tiêu đề đáp ứng Kênh Mới trong Điều D.2.3) chỉ ra rằng một kênh mới đã được tạo ra để làm việc với truyền tải HTTP-UDP, yêu cầu bao gồm trường yêu cầu Kênh Mới được xử lý mặc dù nó được phát trong kênh truyền tải HTTP-UDP mới được tạo ra. Điều này đảm bảo rằng dữ liệu đáp ứng cho yêu cầu đó và tất cả các yêu cầu tiếp theo trong cùng một kênh được đóng khung vào các khúc dữ liệu và cung cấp như là các gói UDP. Dữ liệu đáp ứng này không thể để trống, cho đến khi mọi yêu cầu được phát trên kênh truyền tải HTTP-UDP có một dòng dữ liệu đáp ứng bao gồm ít nhất một bản tin EOR (xem D.3).

Đích đến của các gói tin đáp ứng được cung cấp tùy thuộc vào việc có hay không có yêu cầu kết hợp chứa một trường yêu cầu Gửi đi.

1) Đối với các yêu cầu có chứa trường yêu cầu Gửi đi, các gói dữ liệu được phát đến địa chỉ cụ thể mà không cần bất kỳ bản tin báo nhận nào từ máy khách.

2) Đối với các yêu cầu không chứa trường yêu cầu Gửi đi, các gói tin đáp ứng có thể không được phát đến khi một kết nối UDP bổ trợ được thiết lập. Để làm điều này, máy khách gửi một hoặc nhiều gói tin thiết lập kết nối đến máy chủ được xác định thông qua tiêu đề đáp ứng Kênh Mới, trên cổng được nhận diện bởi tiêu đề đáp ứng Kênh Mới. Mỗi gói tin thiết lập kết nối bắt đầu với tiêu đề bốn byte, theo sau bởi chuỗi ID Kênh kết hợp với kênh HTTP-UDP mới. Một khi máy chủ nhận được gói tin thiết lập kết nối với chuỗi ID Kênh chính xác, nó sẽ gửi tất cả các gói tin đáp ứng tiếp theo (trừ các gói tin liên quan đến trường yêu cầu Gửi Đi) đến địa chỉ IP và cổng mà gói tin thiết lập kênh đến và nó chờ để nhận được gói tin báo nhận từ địa chỉ IP và cổng của máy khách.

CHÚ THÍCH : Do UDP là truyền thông không tin cậy, nên gói tin thiết lập kết nối có thể bị mất. Vì lý do này, máy khách được chuẩn bị để gửi nhiều gói tin thiết lập kết nối nếu cần thiết, và các máy chủ phải được chuẩn bị để loại bỏ gói tin thiết lập kết nối không cần thiết nếu nó đến. Khi nhận được gói tin thiết lập kết nối hợp lệ, máy chủ có thể lựa chọn để lọc các gói tin đến như là một phần của một kế hoạch bảo vệ.

Hai byte đầu tiên của tiêu đề gói tin thiết lập kết nối là FF, trong khi các byte thứ ba và thứ tư nhận diện độ dài của chuỗi ID Kênh, ghi nhận một số 16-bit kiểu big endian. Tiêu đề bốn byte theo sau chuỗi ID Kênh, mã hóa theo các ký tự UTF-8. Nội dung bổ sung có thể được cung cấp, ngoài việc kết thúc của chuỗi ID Kênh, việc biên dịch nội dung như vậy là không được xác định trong tiêu chuẩn này.

K.4 Đáp ứng máy chủ

Trong đáp ứng với mỗi yêu cầu máy khách, máy chủ sẽ gửi trả lời lại một đoạn văn bản HTTP cho máy khách qua kênh chính. Đoạn văn bản trả lời có chứa mã trạng thái, mệnh đề lý do và tất cả các tiêu đề đáp ứng JPIP liên quan và các tiêu đề đáp ứng HTTP bất kỳ thích hợp. Tuy nhiên, không có dữ liệu đáp ứng được phản hồi thông qua kênh chính. Vì lý do này, sẽ không có phần thân thực thể HTTP trong đáp ứng HTTP-UDP. Tiêu đề đáp ứng HTTP hoặc không I sử dụng "Content-length:":" hoặc không sử dụng "Transfer-encoding:".

Bản thân dữ liệu đáp ứng được phân phối thông qua UDP, đóng khung thành nhiều khúc dữ liệu theo cách được mô tả trong J.5. Do truyền tải HTTP-UDP chỉ được sử dụng với các phiên, kiểu trả về ảnh bị hạn chế trong dòng JPP và dòng JPT theo quy định tại Phụ lục A. Do đó, dữ liệu đáp ứng luôn bao gồm các bản tin dòng JPP hoặc dòng JPT liên tục.

Kết quả dữ liệu đáp ứng từ mỗi yêu cầu sẽ bao gồm một số khúc dữ liệu, có nghĩa là không có khúc dữ liệu nào chứa dữ liệu đáp ứng được tạo ra để đáp ứng hai yêu cầu khác nhau.

Đáp ứng đối với mỗi và mọi yêu cầu sau đây mà một trong những kênh được yêu cầu, được kết thúc bằng bản tin EOR, ngay cả khi dữ liệu đáp ứng rỗng. Bản tin EOR được coi là một phần của dữ liệu đáp ứng.

Điều này có nghĩa rằng tất cả các yêu cầu đưa ra trên kênh JPIP truyền tải HTTP-UDP là kết quả của việc tạo ra của ít nhất một khúc dữ liệu đáp ứng không rỗng từ máy chủ và khúc dữ liệu cuối cùng được tạo ra để đáp ứng cho từng yêu cầu kết thúc với bản tin EOR.

Tất cả dữ liệu đáp ứng được gửi bởi máy chủ thông qua kết nối UDP bổ trợ được đóng khung thành các khúc dữ liệu. Mỗi khúc bao gồm một tiêu đề khúc 8-byte, tiếp theo là phần thân của khúc chứa dữ liệu đáp ứng của máy chủ, như trong Hình K.1. Các tiêu đề và phần thân được gửi dưới dạng gói tin UDP đơn lẻ, có chiều dài chính xác bằng độ dài của phần thân khúc cộng thêm 8 tính theo byte. Hơn nữa, không có gói tin UDP nào sẽ có độ dài lớn hơn 4096 byte hoặc có độ dài nhỏ hơn 8 byte. Từ 2 byte đầu tiên của tiêu đề khúc dữ liệu giữ một số nguyên không dấu kiểu big endian, có biên dịch như trường "control" được quy định tại Bảng K.1.

6 byte còn lại của tiêu đề khúc dữ liệu chứa 16 bit trọng số thấp của ID Yêu cầu được cung cấp bởi máy khách trong các yêu cầu gán với dữ liệu đáp ứng của khúc dữ liệu, cùng với trường "repeat" một byte và số thứ tự khúc 24 bit được mã hóa như số nguyên không dấu kiểu big endian. Số thứ tự khúc dữ liệu là số được tạo bởi máy chủ, bắt đầu từ không và sẽ được tăng thêm một cho mỗi khúc dữ liệu tiếp theo gửi cho máy khách để đáp ứng cùng một yêu cầu.

Các yêu cầu mới từ máy khách sẽ khiến số thứ tự khúc dữ liệu bị thiết lập lại bắt đầu từ 0 cho khúc dữ liệu đầu tiên được gửi trong đáp ứng của yêu cầu mới. Số thứ tự khúc dữ liệu không thể hoán đổi, và các máy chủ sẽ chỉ ra lỗi bằng cách sử dụng 7 mã lý do EOR (đạt giới hạn đáp ứng), xem D.3 trong trường hợp hết số thứ tự có sẵn.

Trường "repeat" một byte có thể được sử dụng bởi máy chủ bằng bất kỳ cách nào. Thông thường, trường "repeat" sẽ được sử dụng để phân biệt giữa các phiên bản khúc dữ liệu gốc và truyền lại, cho phép máy chủ quyết định trường hợp khúc dữ liệu là báo nhận trong gói tin báo nhận. Tuy nhiên, trường này có thể có khả năng được sử dụng theo những cách khác. Máy khách không nên cố gắng biên dịch trường "repeat" nhưng phải tái tạo nó trong các gói dữ liệu báo nhận trả về.

CHÚ THÍCH: ID Yêu cầu và số thứ tự khúc dữ liệu cho phép khúc dữ liệu được sắp xếp lại đúng theo thứ tự. Chúng cũng cung cấp phương thức để phát hiện khúc dữ liệu bị mất. Máy khách có thể phát hiện sự mất mát của các khúc bằng cách kiểm tra các thiết lập của số thứ tự khúc dữ liệu với những khoảng trống hoặc phát hiện các máy chủ đã không được truyền khúc dữ liệu chứa bản tin EOR; sau này sẽ nằm trong trong khúc dữ liệu cuối cùng được gửi để đáp ứng yêu cầu. Máy khách có thể sử dụng trường yêu cầu Bỏ qua để thông báo một cách rõ ràng cho máy chủ về khúc dữ liệu bị mất. Máy khách có thể lựa chọn để trì hoãn việc sử dụng các cơ chế hoặc không sử dụng chúng, theo quyết định của chúng.