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



tải về 8.86 Mb.
trang8/40
Chuyển đổi dữ liệu01.12.2017
Kích8.86 Mb.
#34910
1   ...   4   5   6   7   8   9   10   11   ...   40

B.2 Kênh và phiên

Các yếu tố sau đây được kết hợp với mỗi phiên:

- Một hoặc nhiều địa chỉ logic (thường là tập tin hình ảnh), có nội dung không thay đổi so với phiên.

- Một kiểu dữ liệu ảnh trả về duy nhất cho mỗi địa chỉ logic liên quan đến phiên.

- Đối với mỗi địa chỉ logic kết hợp với phiên, một mô hình cho nội dung bộ nhớ đệm của máy khách phải được duy trì bất cứ nơi nào các kiểu dữ liệu trả về là một trong những "dòng JPP" hoặc "dòng JPT". Lưu ý, mô hình này không cần phải hoàn hảo, phản ánh tình trạng thực tế của bộ nhớ đệm trên máy khách. Quy tắc về việc bảo trì các mô hình bộ nhớ đệm được nêu trong Điều B.3.

- Một hoặc nhiều kênh JPIP. Máy khách nói chung có thể mở nhiều kênh trong cùng một phiên. Mỗi kênh JPIP có thể được liên kết với một kênh truyền tải lớp dưới riêng biệt (ví dụ, một kết nối TCP riêng), mặc dù điều này có thể không phải là cá biệt. Nhiều kênh cho phép máy khách phát đi yêu cầu đồng thời cho nhiều vùng ảnh, với hy vọng rằng các máy chủ sẽ đáp ứng những yêu cầu này đồng thời. Các kênh cũng cho phép phân bổ băng thông thông minh giữa các loại khác nhau của các yêu cầu hoặc trong một hình ảnh đích đơn lẻ hoặc thông qua nhiều đích.

- Trường hợp nhiều kênh khác nhau có liên quan đến cùng một địa chỉ logic, mô hình bộ nhớ đệm cho phiên được áp dụng trên tất cả các kênh. Nhiều máy khách có thể mở các kênh JPIP trong cùng một phiên, mặc dù điều này có thể có tác dụng phụ không mong muốn nếu các kênh tham chiếu cùng một địa chỉ logic.

Các yếu tố sau đây được kết hợp với mỗi kênh:

- Một địa chỉ logic duy nhất (thường là một tập tin hình ảnh).

- Một định danh gán với máy chủ sẽ được bao gồm trong mỗi yêu cầu. JPIP không định nghĩa một định danh phiên riêng biệt, do định danh kênh đủ để kết hợp các yêu cầu cho phiên.

- Một bản ghi khả năng và ưu tiên của máy khách, có thể được điều chỉnh thông qua các trường yêu cầu thích hợp.

- Trong phạm vi mà hàng đợi máy chủ yêu cầu, nó sẽ cung cấp một hàng đợi riêng cho mỗi kênh JPIP.

Có một sự tương quan một-một cho các yêu cầu của máy khách và đáp ứng của khách hàng trên một kênh. Các kênh JPIP khác nhau có thể trên cùng một kênh truyền tải hoặc trên các kênh truyền tải khác nhau. Các yêu cầu sử dụng các kênh JPIP khác nhau có thể đến không đồng bộ với máy chủ nếu các sử dụng các kênh truyền tải riêng để vận chuyển các yêu cầu. Các đáp ứng sử dụng các kênh JPIP khác nhau có thể đến không đồng bộ với máy khách nếu sử dụng các kênh truyền tải riêng để vận chuyển các đáp ứng. Phục vụ của nhiều kênh là quyết định của máy chủ, tuy nhiên, các trường yêu cầu tỷ lệ phân phối và băng thông tối đa và ưu tiên băng thông được hướng dẫn cho các máy chủ.

B.3 Quản lý mô hình bộ nhớ đệm

Như đã đề cập, một trong những chức năng chính của một phiên là các mô hình phía máy chủ của bộ nhớ đệm máy khách. Trừ khi thông báo rõ ràng, máy chủ có thể giả định rằng máy khách lưu trữ tất cả thông tin được gửi để đáp ứng yêu cầu trong phiên: thông tin này không cần phải được gửi lại. Lưu ý, các máy chủ không có nghĩa vụ duy trì mô hình bộ nhớ đệm đầy đủ hoặc mô hình bộ nhớ đệm bất kỳ ở tất cả: dữ liệu dư thừa có thể được truyền để đáp ứng yêu cầu.

Ngoài tác động của dữ liệu truyền, các câu lệnh thao tác mô hình bộ nhớ đệm rõ ràng trong các yêu cầu của máy khách có thể cập nhật mô hình bộ nhớ đệm của máy chủ. Các báo cáo này sẽ được xử lý trước khi xác định dữ liệu đó phải được trả về cho máy khách để đáp ứng với yêu cầu của nó. Có hai loại câu lệnh thao tác mô hình bộ nhớ đệm: Thêm và bớt.

Câu lệnh thao tác thêm vào mô hình bộ nhớ đệm phục vụ để tăng cường mô hình bộ nhớ đệm của máy chủ, thêm ngăn dữ liệu, hoặc các phần của ngăn dữ liệu vào mô hình hiện tại. Chúng cung cấp một cơ chế cho máy khách để thông báo cho máy chủ về thông tin mà nó nhận được trong phiên trước đó, hoặc sử dụng các yêu cầu phi trạng thái trước đó. Một máy chủ nên cố gắng khai thác câu lệnh thao tác thêm vào mô hình bộ nhớ đệm xuất hiện trong các yêu cầu của máy khác. Tuy nhiên, các máy chủ không bắt buộc phải duy trì mô hình bộ nhớ đệm đầy đủ, do đó, máy chủ có thể bỏ qua hoặc bỏ qua một phần, Câu lệnh thao tác thêm vào mô hình bộ nhớ đệm

Câu lệnh bớt phục vụ việc loại bỏ ngăn dữ liệu, hoặc các phần của ngăn dữ liệu từ mô hình bộ nhớ đệm của máy chủ. Một máy khách có thể phát đi câu lệnh thao tác bớt đi mô hình bộ nhớ đệm để thông báo cho máy chủ rằng nó đã không được lưu trữ hoặc đã bỏ đi một số dữ liệu mà trước đây đã được gửi cho các máy chủ. Các máy chủ tự do giả định rằng máy khách đã lưu trữ tất cả dữ liệu truyền trong phiên. Các máy chủ sẽ loại bỏ tất cả các thông tin xác định bởi câu lệnh thao tác bớt đi mô hình bộ nhớ đệm từ bất kỳ mô hình bộ nhớ đệm (hoàn chỉnh hay cách khác) rằng nó được duy trì.

Yêu cầu JPIP dựa trên phiên có các tác dụng phụ, có thể ảnh hưởng đến đáp ứng các yêu cầu trong tương lai. Điều này cũng đúng với các yêu cầu có chứa câu lệnh thao tác mô hình bộ nhớ đệm - ảnh hưởng của thao tác mô hình bộ nhớ đệm là liên tục. Hơn nữa, tác dụng phụ của yêu cầu đến kênh JPIP được phản ánh trong đáp ứng với bất kỳ yêu cầu có thể thuộc về một kênh JPIP khác được kết hợp với cùng một địa chỉ logic. Điều này xuất phát từ thực tế là chỉ có một mô hình bộ nhớ đệm cho mỗi địa chỉ logic trong một phiên.



B.4 Truy vấn và thao tác tập mô hình

Khi một địa chỉ logic kết hợp với một phiên có chứa một số lượng lớn các dòng mã (ví dụ, địa chỉ hình ảnh), hoặc một máy khách vẫn còn kết nối trong một thời gian dài, một phần mô hình bộ nhớ đệm trở thành một chiến lược ngày càng có khả năng cho việc triển khai máy chủ thực tế. Nó cũng trở nên ngày càng có khả năng là do máy khách sẽ không thể lưu đệm tất cả thông tin được gửi bởi máy chủ. Đề tránh giao tiếp thiếu hiệu quả trong hoàn cảnh như vậy, khái niệm về một "mset" (model-set) được giới thiệu. Các "mset" là tập hợp của các dòng mã mà nội dung bộ nhớ đệm của máy khách được được mô hình hóa bởi các máy chủ.

Trong yêu cầu bất kỳ, máy khách có thể hướng dẫn máy chủ để hạn chế "mset" của mình cho một tập các dòng mã. Điều này cung cấp một cơ chế thuận tiện cho máy khách loại bỏ toàn bộ các dòng mã từ bộ nhớ đệm của chúng mà không cần chạy, các nguy cơ máy chủ sẽ tạo ra các đáp ứng đầy đủ cho các yêu cầu trong tương lai của các dòng mã.

Các yêu cầu "mset" là kết quả của các đáp ứng máy chủ chỉ ra tập thực tế của các dòng mã để duy trì thông tin mô hình bộ nhớ đệm. Điều này cho phép máy khách xác định có hay câu lệnh thao tác mô hình bộ nhớ đệm trong đó đề cập đến một loạt các dòng mã được bỏ qua bởi máy chủ.

Trong trường hợp không có bất kỳ truy vấn hoặc thao tác "mset" rõ ràng nào, máy khách có thể giả định rằng "mset" của máy chủ chỉ bao gồm tất cả các dòng mã tạo ra các dữ liệu đáp ứng theo yêu cầu của mình. Do các máy chủ nói chung có quyền giới hạn phạm vi yêu cầu của máy khách với số lượng dòng mã nhỏ hơn số ban đầu cho trước, không có đảm bảo rằng "mset" của máy chủ sẽ bao gồm tất cả các dòng mã đề cập trong một yêu cầu, trừ khi yêu cầu chỉ đề cập đến một dòng mã. Những vấn đề này được giải thích thêm trong Điều C.8.6.
Phụ lục C

(Quy định)

Yêu cầu của máy khách

C.1 Cú pháp yêu cầu

C.1.1 Tổng quan

Phụ lục này mô tả tất cả các yếu tố có thể có trong một yêu cầu JPIP. Mỗi điều khoản nhỏ mô tả một nhóm các trường và các giá trị có thể cho các trường này. Nói chung, một yêu cầu sẽ bao gồm các trường từ nhiều nhóm, nhưng cũng có một số nhóm không tương thích. Trong mỗi nhóm, cũng có một số trường yêu cầu không phù hợp. Một số yêu cầu hợp lệ khác có thể không có giá trị sử dụng trong một số trường hợp (chẳng hạn, như các phiên), mặc dù điều này không được chỉ ra bởi các cú pháp BNF. Cuối cùng, ngay cả với một yêu cầu phù hợp, một máy chủ có thể không thực hiện tất cả các trường yêu cầu có thể hoặc kết hợp there-of, nhưng nó phải phân tích và biên dịch tất cả các trường yêu cầu và đáp ứng chính thức một cách thích hợp, ngay cả khi đáp ứng lỗi. Thông tin chi tiết về những gì máy chủ dự kiến để thực hiện được quy định tại Phụ lục J.

CHÚ THÍCH: Những đáp ứng hoặc các phương pháp báo hiệu lỗi phụ thuộc vào các lớp truyền tải được sử dụng. Điều D.1 cung cấp các ví dụ về các máy chủ sử dụng HTTP như là giao thức truyền dẫn.

C.1.2 Cấu trúc yêu cầu

Yêu cầu, JPIP bao gồm các trường sau đây:

- Các trường xác định Địa chỉ;

- Các trường quản lý kênh và phiên;

- Các trường yêu cầu Cửa sổ hiển thị;

- Trường dữ liệu đặc tả;

- Các trường yêu cầu hạn chế dữ liệu;

- Các trường yêu cầu điều khiển máy chủ;

- Các trường yêu cầu quản lý bộ nhớ đệm;

- Các trường yêu cầu tải lên;

- Các trường tham chiếu và năng lực của máy khách.

Các thành phần trong yêu cầu sẽ được gửi phù hợp với các giao thức truyền tải được chọn. Ví dụ, trong HTTP, các yêu cầu được thể hiện bằng các ký tự được liệt kê trong cú pháp BNF, nhiều tham số được kết hợp bởi ký tự "&", và các yêu cầu có thể là một phần của trường truy vấn của yêu cầu GET, hoặc phần thân của yêu cầu POST. Xem phụ lục F, G và H để biết thêm chi tiết.



Các trường trong yêu cầu được gửi phù hợp với các giao thức truyền tải được chọn. Ví dụ, trong HTTP, các yêu cầu có thể là một phần của trường truy vấn của yêu cầu GET, hoặc phần thân của yêu cầu POST, với các trường yêu cầu riêng phân tách với nhau bởi ký tự "&" (xem Phụ lục F, G và H để biết thêm chi tiết). Trong ngữ cảnh như thế này, một số ký tự được tìm thấy trong cú pháp BNF hoặc các tham số yêu cầu phải thoát ra để tránh sự nhập nhằng. Ví dụ, một trường yêu cầu có dạng "target=me&my dog" trong ngữ cảnh HTTP nên được chuyển ngữ thành "target=me%26my%20dog", để tránh nhầm lẫn với "&" được sử dụng để phân tách các trường yêu cầu. Một ví dụ khác, "metareq=[roid/w]" trong ngữ cảnh HTTP nên chuyển ngữ thành "metareq=%5broid/w%5d" để tránh việc sử dụng ký tự non-URI (xem IETF RFC 2396 để biết thêm trên về các ký tự dành riêng), làm rõ nghĩa và chuyển ngữ qua quá trình mã hóa hex-hex. Phân tích cú pháp của các yêu cầu được tìm thấy trong ngữ cảnh như vậy cần được chuẩn bị để thực hiện giải mã hex-hex của từng trường yêu cầu.



C.1.3 Các giới hạn trên các trường yêu cầu kết hợp

Mỗi loại trường yêu cầu JPIP sẽ xuất hiện không quá một lần trong một yêu cầu.

Nhìn chung, các yêu cầu về dữ liệu hình ảnh (các yêu cầu Cửa sổ hiển thị) có thể được kết hợp với các yêu cầu bổ sung dữ liệu đặc tả. Tuy nhiên, có những hạn chế về cách kết hợp các trường yêu cầu.

Trường yêu cầu tải lên sẽ không được kết hợp với metadata-field hoặc data-limit-field hoặc server-control-field



C.2 Các trường xác định Địa chỉ

C.2.1 Giới thiệu về các địa chỉ logic

Mỗi yêu cầu JPIP hướng đến một đại diện cụ thể của tài nguyên được chỉ rõ nguồn gốc cụ thể hoặc một phần cụ thể của tài nguyên đó. Đó có thể là một tập tin hoặc đối tượng được lưu trữ vật lý, hoặc có thể là một cái gì đó được tạo ra chính thức bởi các yêu cầu trên máy chủ.

Các đại diện cụ thể, cho dù đó là hình thức mã hóa ban đầu hay hình thức chuyển mã, hoặc cho dù đó là một loạt byte cụ thể hay toàn bộ tài nguyên, được gọi là địa chỉ logic. Địa chỉ logic được xác định thông qua ba trường yêu cầu: ID Địa chỉ, Địa chỉ và Địa chỉ Phụ.

Trường yêu cầu Địa chỉ xác định tài nguyên được chỉ rõ nguồn gốc từ những yêu cầu trực tiếp. Nó được xác định bằng cách sử dụng PATH, có thể là một chuỗi đơn giản hoặc một URI. Nếu trường Địa chỉ không được xác định và yêu cầu được thực hiện qua HTTP (hay HTTPS), sau đó yêu cầu JPIP sẽ được hướng đến các tài nguyên xác định thông qua các thành phần đường dẫn URL của yêu cầu JPIP. Tài nguyên được chỉ rõ nguồn gốc này có thể là một tập tin thực tế hoặc đối tượng khác được lưu trữ trên máy chủ, hoặc nó có thể là một cái gì đó mà máy chủ tạo ra để đáp ứng với yêu cầu JPIP.

Các trường yêu cầu Địa chỉ Phụ xác định cụ thể phạm vi byte của tài nguyên được chỉ rõ nguồn gốc (xác định thông qua các trường yêu cầu Địa chỉ) mà yêu cầu được hướng tới. Nếu trường yêu cầu Địa chỉ Phụ không được xác định, các yêu cầu được gửi cho toàn bộ dãy byte của tài nguyên ban đầu.

Trường yêu cầu ID Địa chỉ có thể được sử dụng để tiếp tục xác định một quá trình mã hóa đặc biệt của tài nguyên trong trường hợp máy chủ và máy khách đã từng trao đổi dữ liệu từ các tài nguyên này. Ví dụ, máy chủ có thể đã từng cung cấp một phiên bản chuyển mã các tập tin cho máy khách dựa trên thông tin cung cấp và các điều kiện xung quanh một yêu cầu trước đó. Nếu máy khách đã lưu các dữ liệu trước đây đã truyền đi trong bộ nhớ đệm của nó, nó sẽ muốn tiếp tục nhận được dữ liệu bằng cách sử dụng cùng một mã để có thể tiếp tục sử dụng các dữ liệu trong bộ nhớ đệm. ID Địa chỉ là một chuỗi nhận diện dạng máy chủ xác định, mà các máy chủ trước đây đã liên kết với đại diện cụ thể đó của tài nguyên được chỉ rõ nguồn gốc cụ thể, hoặc một dãy byte của một số tài nguyên được chỉ rõ nguồn gốc cụ thể.

Nếu một máy khách xác định cả hai tài nguyên được chỉ rõ nguồn gốc (thông qua một trong hai trường yêu cầu Địa chỉ hoặc thông qua các thành phần đường dẫn URL của yêu cầu JPIP) và ID Địa chỉ, máy chủ sẽ xác minh có hay không có nó để có thể đáp ứng yêu cầu theo cách tương tự như khi nó được gán với ID Địa chỉ của nguồn tài nguyên đó. Nếu máy chủ không thể đáp ứng theo cách tương tự, nó sẽ sử dụng một tiêu đề đáp ứng JPIP-tid để thông báo cho máy khách của một ID Địa chỉ mới, lúc đó máy khách sẽ biết rằng nó phải loại bỏ bất kỳ dữ liệu được lưu trữ trước đó.

Nếu một địa chỉ logic dùng để phục vụ các bản tin dòng JPP hoặc dòng JPT, các ngăn dữ liệu liên quan sẽ vẫn phù hợp trong tất cả các đáp ứng được phát đi trong cùng một phiên. Trong trường hợp máy chủ, hoặc máy chủ có liên quan, cũng phát đi một ID Địa chỉ, thì các ngăn dữ liệu sẽ vẫn phù hợp trên tất cả các đáp ứng phát đi cùng một ID Địa chỉ, cho dù chúng có được phát đi trong cùng một phiên hay không.

Nếu trường yêu cầu ID Kênh được bao gồm trong yêu cầu, thì yêu cầu không cần phải bao gồm các trường ID Địa chỉ, Địa chỉ và Địa chỉ Phụ.

Các ví dụ sau đây cho thấy các đặc điểm kỹ thuật của các địa chỉ logic:

VÍ DỤ 1: Đối với URL của yêu cầu JPIP

"http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&fsiz=200.00" địa chỉ logic là toàn bộ dãy byte chứa trong các URI "http://one.jpeg.org/images/picture.jp2. " liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 2: Đối với URL của yêu cầu JPIP là



"http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&tid=4384-5849-af4d-3dca&fsiz=200.200" địa chỉ logic là toàn bộ dãy byte chứa trong các URI "http://one.jpeg.org/images/picture.jp2." liên quan đến thư mục tài liệu gốc máy chủ, với một đạl diện được xác định bởi các máy chủ với ID Địa chỉ 4384-5849-af4d-3dca .

VÍ DỤ 3: Đối với URL của yêu cầu JPIP



"http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&subtarget=1.038-13.458&fsiz=200.200" địa chỉ logic là một loạt các byte, bắt đầu với byte 1038, và tất cả các byte lớn hơn và bao gồm byte 13458, chứa trong các URI "http://one.jpeg.org/images/picture.jp2." liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 4: Đối với URL của yêu cầu JPIP "http://one.jpeg.org/imageserver.cgi?cid=1234-5849-af4d-3dca&fsiz=200.200" địa chỉ logic là tài nguyên mà máy chủ đã liên kết với các kênh có ID 1234-5849-af4d-3dca.

VÍ DỤ 5: Đối với URL của yêu cầu JPIP "http://one.jpeg.org/images.jp2?fsiz=200.200" địa chỉ logic là toàn bộ phạm vi byte chứa trong các tập tin "lmages/picture.jp2", liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 6: Đối với URL của yêu cầu JPIP "http://one.jpeg.org/images/picture.jp2?subtarget=1038-13458&fsiz=200.200" địa chỉ logic là một loạt các byte, bắt đầu với byte 1038, và tất cả các byte lớn hơn và bao gồm byte 13458, chứa trong các tập tin "images/picture.jp2." liên quan đến thư mục tài liệu gốc máy chủ.



C.2.2 Địa chỉ (target)

target = "target" "=" PATH



Trường này được sử dụng để chỉ ra tài nguyên được chỉ rõ nguồn gốc (thường là tên của một tập tin trên máy chủ). Nếu trường yêu cầu Địa chỉ bị mất thì các tài nguyên được đặt tên gốc sẽ được xác định bằng các phương tiện khác.

C.2.3 Địa chỉ Phụ (subtarget)

Trường này có thể được sử dụng để xác định tài nguyên được chỉ rõ nguồn gốc thông qua các đặc điểm kỹ thuật của một dãy byte hoặc một dãy các dòng mã trong tài nguyên ban đầu. Địa chỉ logic được hiểu là phạm vi byte chỉ định hoặc một loạt các dòng mã của tài nguyên được chỉ rõ nguồn gốc. Với mục đích của các yêu cầu và đáp ứng liên quan đến địa chỉ logic này, dòng mã trong địa chỉ này sẽ được gán các chỉ số liên tiếp bắt đầu từ số không.

CHÚ THÍCH: Việc xác định địa chỉ logic cho một loạt các dòng mã cần phải dán nhãn lại các dòng mã, và thay thế hiệu quả các chỉ số dòng mã, nếu có, trong tài nguyên được chỉ rõ nguồn gốc bằng các chỉ số liên tiếp bắt đầu từ số không.

Các giới hạn trên và dưới của dãy byte được cung cấp đã bao gồm, trong đó các byte hoặc các dòng mã được đếm từ không.



Каталог: data -> 2017
2017 -> Tcvn 6147-3: 2003 iso 2507-3: 1995
2017 -> Các Cục Hải quan tỉnh, thành phố
2017 -> TIÊu chuẩn quốc gia tcvn 10256: 2013 iso 690: 2010
2017 -> Căn cứ Nghị định số 15/2017/NĐ-cp ngày 17/02/2017 của Chính phủ quy định chức năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ Nông nghiệp và Phát triển nông thôn
2017 -> TIÊu chuẩn quốc gia tcvn 8400-3: 2010
2017 -> TIÊu chuẩn nhà NƯỚc tcvn 3133 – 79
2017 -> Căn cứ Luật Tổ chức chính quyền địa phương ngày 19 tháng 6 năm 2015
2017 -> Căn cứ Nghị định số 15/2017/NĐ-cp ngày 17 tháng 02 năm 2017 của Chính phủ quy định chức năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ Nông nghiệp và Phát triển nông thôn
2017 -> Btvqh10 ngày 25 tháng 5 năm 2002 của Ủy ban Thường vụ Quốc hội về tự vệ trong nhập khẩu hàng hóa nước ngoài vào Việt Nam

tải về 8.86 Mb.

Chia sẻ với bạn bè của bạn:
1   ...   4   5   6   7   8   9   10   11   ...   40




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương