Features
기능
GATT features are strictly defined procedures that allow GATT-based data exchanges to take place.
GATT 기능은 GATT 기반 데이터 교환이 이루어질 수 있도록 엄격하게 정의된 절차입니다.
They are all based on the different operations that ATT provides (introduced in “ATT operations” on page 26).
이는 모두 ATT가 제공하는 다양한 작업을 기반으로 합니다 (26페이지의 "ATT 작업"에서 소개됨).
To a certain extent, most of the features listed in this chapter are exposed in one way or another in most GATT APIs.
어느 정도 이 장에 나열된 대부분의 기능은 대부분의 GATT API에서 어떤 방식으로든 노출됩니다.
GATT server APIs add the ability to populate the actual server with attributes, but that is heavily implementation dependant and beyond the scope of this chapter.
GATT 서버 API는 실제 서버에 속성을 채우는 기능을 추가하지만 이는 구현에 크게 좌우되며 이 장의 범위를 벗어납니다.
This succinct two-packet procedure allows each ATT peer to let the other end know about the maximum transmission unit (MTU, or effectively maximum packet length) it can hold in its buffers and can therefore accept.
이 간결한 두 패킷 절차를 통해 각 ATT 피어는 버퍼에 보유할 수 있고 따라서 수락할 수 있는 최대 전송 단위(MTU 또는 사실상 최대 패킷 길이)에 대해 상대방에게 알릴 수 있습니다.
This procedure is used only whenever either the client or the server (or both) can handle MTUs longer than the default ATT_MTU of 23 bytes (see “Logical Link Control and Adaptation Protocol (L2CAP)” on page 25) and wants to inform the other end that it can send packets longer than the default values that the specification requires.
이 절차는 클라이언트나 서버 (또는 둘 다)가 기본 ATT_MTU인 23바이트보다 긴 MTU를 처리할 수 있고 (25페이지의 "논리 링크 제어 및 적응 프로토콜 (L2CAP)" 참조) 사양에서 요구하는 기본값보다 긴 패킷을 보낼 수 있음을 다른 쪽에게 알리려는 경우에만 사용됩니다.
L2CAP will then fragment these bigger packets into small Link Layers packets and recombine them from small Link Layers packets.
그런 다음 L2CAP는 이러한 더 큰 패킷을 작은 링크 계층 패킷으로 조각화하고 작은 링크 계층 패킷에서 다시 결합합니다.
Service and Characteristic Discovery
서비스 특성 발견
As mentioned elsewhere in this chapter, the client has no knowledge about the attributes that might be present in a GATT server when it first connects to it.
이 장의 다른 부분에서 언급했듯이 클라이언트는 처음 연결할 때 GATT 서버에 존재할 수 있는 속성에 대한 지식이 없습니다.
It is therefore essential for the client to begin by performing a series of packet exchanges to determine the amount, location, and nature of all the attributes that might be of interest.
따라서 클라이언트는 관심을 가질 수 있는 모든 속성의 양, 위치 및 특성을 결정하기 위해 일련의 패킷 교환을 수행하는 것부터 시작하는 것이 중요합니다.
As discussed in “Attribute Caching” on page 66, procedures in this category can, in some cases, subsequently be skipped.
66페이지의 "속성 캐싱"에서 설명한 대로 이 범주의 절차는 경우에 따라 이후에 건너뛸 수 있습니다.
For primary service discovery, GATT offers the two following options:
기본 서비스 검색을 위해 GATT는 다음 두 가지 옵션을 제공합니다:
Using this feature, clients can retrieve a full list of all primary services (regardless of service UUIDs) from the remote server.
이 기능을 사용하면 클라이언트는 원격 서버에서 서비스 UUID에 관계없이 모든 기본 서비스의 전체 목록을 검색할 수 있습니다.
This is commonly used when the client supports more than one service and therefore wants to find out about the full service support on the server side.
이는 클라이언트가 둘 이상의 서비스를 지원하므로 서버 측의 전체 서비스 지원에 대해 알고 싶을 때 일반적으로 사용됩니다.
Because the client can specify a handle range when issuing the required request, it must set 0x0001-0xFFFF as the handle range to implement this feature, covering the full attribute range of the server.
클라이언트는 필요한 요청을 발행할 때 핸들 범위를 지정할 수 있으므로 이 기능을 구현하기 위해 핸들 범위로 0x0001-0xFFFF를 설정해야 하며, 이는 서버의 전체 속성 범위를 포괄해야 합니다.
UUID Whenever the client knows which service it is looking for (usually because it supports only that single service itself), it can simply look for all instances of a particular service using this feature, also with the requirement of setting the handle range to 0x0001-0xFFFF.
UUID 클라이언트가 어떤 서비스를 찾고 있는지 알고 있는 경우 (일반적으로 해당 서비스 하나만 지원하기 때문에) 이 기능을 사용하여 특정 서비스의 모든 인스턴스를 간단히 찾을 수 있으며, 핸들 범위를 0x0001-0xFFFF로 설정해야 합니다.
Each of these procedures yield handle ranges that refer to the attributes that belong to a single service.
이러한 각 프로시저는 단일 서비스에 속하는 속성을 참조하는 핸들 범위를 생성합니다.
The discover all primary services feature also obtains the individual service UUIDs.
모든 기본 서비스 검색 기능은 개별 서비스 UUID도 가져옵니다.
When the client has already found services on the server, it can proceed to perform relationship discovery (the discovery of any included services) with the following feature:
클라이언트가 서버에서 이미 서비스를 찾은 경우 다음 기능을 사용하여 관계 검색 (포함된 서비스 검색) 수행을 진행할 수 있습니다 .
Find included services
포함된 서비스 찾기
This allows a client to query the server about any included services within a service.
이를 통해 클라이언트는 서비스 내에 포함된 서비스에 대해 서버에 쿼리할 수 있습니다.
The handle range provided in such a query refers to the boundaries of an existing service, previously obtained using service discovery.
이러한 쿼리에 제공되는 핸들 범위는 이전에 서비스 검색을 통해 얻은 기존 서비스의 경계를 나타냅니다.
As with service discovery, the client also receives a set of handle ranges, along with UUIDs when applicable.
서비스 검색과 마찬가지로 클라이언트는 해당되는 경우 UUID와 함께 일련의 핸들 범위도 수신합니다.
In terms of characteristic discovery, GATT offers the following options:
특성 발견 측면에서 GATT는 다음과 같은 옵션을 제공합니다:
Discover all characteristics of a service
서비스의 모든 특성을 검색합니다
Once a client has obtained the handle range for a service it might be interested in, it can then proceed to retrieve a full list of its characteristics.
클라이언트가 관심을 가질 수 있는 서비스에 대한 핸들 범위를 얻은 후에는 해당 특성의 전체 목록을 검색할 수 있습니다.
The only input is the handle range, and in exchange, the server returns both the handle and the value of all characteristic declaration attributes enclosed within that service (see “Characteristic declaration attribute” on page 59).
유일한 입력은 핸들 범위이며, 그 대가로 서버는 핸들과 해당 서비스 내에 포함된 모든 특성 선언 속성의 값을 모두 반환합니다 (59페이지의 "특성 선언 속성" 참조).
This procedure is identical to the previous one, except the client discards all responses that do not match the particular characteristic UUID it targets.
이 절차는 클라이언트가 대상으로 삼는 특정 특성 UUID와 일치하지 않는 모든 응답을 삭제한다는 점을 제외하면 이전 절차와 동일합니다.
Once the boundaries (in terms of handles) of a target characteristic have been established, the client can go on to characteristic descriptor discovery:
대상 특성의 경계 (핸들의 측면에서)가 설정되면 클라이언트는 특성 설명자 검색을 진행할 수 있습니다:
Now in possession of a set of handle ranges and UUIDs for some or all of the characteristics in a service, the client can use this feature to retrieve all the descriptors within a particular characteristic.
이제 서비스의 일부 또는 전체 특성에 대한 일련의 핸들 범위 및 UUID를 소유한 클라이언트는 이 기능을 사용하여 특정 특성 내의 모든 설명자를 검색할 수 있습니다.
The server replies with a list of UUID and handle pairs for the different descriptor declarations (see “Characteristic Descriptors” on page 61).
서버는 UUID 목록으로 응답하고 다양한 설명자 선언에 대한 쌍을 처리합니다 (61페이지의 "특성 설명자" 참조).
All the features in this section can be performed over open, unsecured connections, because discovery is allowed for all clients without any restrictions.
이 섹션의 모든 기능은 모든 클라이언트에 대해 제한 없이 검색이 허용되므로 개방적이고 보안되지 않은 연결에서 수행할 수 있습니다.
Reading Characteristics and Descriptors
읽기 특성 및 설명자
To obtain the current value of a characteristic value or a descriptor, the client has the following choices:
특성 값이나 설명자의 현재 값을 얻기 위해 클라이언트는 다음 선택 사항을 갖습니다:
Read characteristic value or descriptor
특성 값 또는 설명자 읽기
This feature can be used to simply read the contents of a characteristic value or a descriptor by using its handle.
이 기능은 핸들을 사용하여 특성 값이나 설명자의 내용을 간단히 읽는 데 사용할 수 있습니다.
Only the first ATT_MTU-1 bytes of the contents can be read, because that is the maximum number of bytes that can fit in the response packet (1 byte is reserved for the ATT operation code).
내용의 첫 번째 ATT_MTU-1 바이트만 읽을 수 있습니다. 이는 응답 패킷에 들어갈 수 있는 최대 바이트 수이기 때문입니다 (1바이트는 ATT 작업 코드용으로 예약되어 있음).
Read long characteristic value or descriptor
긴 특성 값 또는 설명자 읽기
If the value is too long to be read with the previous feature, this feature includes an offset along with the handle in the request, so that the characteristic value or the descriptor contents can be read in successive chunks.
값이 너무 길어서 이전 기능으로는 읽을 수 없는 경우, 이 기능은 요청에 핸들과 함께 오프셋을 포함시켜서 특성 값이나 설명자 내용을 연속적인 청크로 읽을 수 있습니다.
Multiple request/response pairs might be required, depending on the length of the attribute value being read.
읽고 있는 속성 값의 길이에 따라 여러 요청/응답 쌍이 필요할 수 있습니다.
Additionally, and only applicable for characteristic values, these features are available:
또한 특성 값에만 적용 가능하며 다음 기능을 사용할 수 있습니다:
Read characteristic value using characteristic UUID
특성 UUID를 사용하여 특성 값 읽기
Whenever a client does not know the specific handles for the characteristics it might be interested in, it can read the values of all the characteristics of a specific type.
클라이언트가 관심이 있을 수 있는 특성에 대한 특정 핸들을 모를 때마다 특정 유형의 모든 특성 값을 읽을 수 있습니다.
The client simply provides a handle range and a UUID and receives an array of values of characteristics enclosed in that range.
클라이언트는 단순히 핸들 범위와 UUID를 제공하고 해당 범위에 포함된 특성 값의 배열을 받습니다.
Read multiple characteristic values
여러 특성 값 읽기
Conversely, if a client already has the handles for a set of characteristics it wants to obtain the value from, it can then send a request with this set of handles and subsequently receive the values for all corresponding characteristics.
반대로, 클라이언트가 값을 얻고자 하는 특성 집합에 대한 핸들을 이미 가지고 있는 경우, 이 핸들 집합과 함께 요청을 보내면 이후 해당 특성에 대한 모든 값을 수신할 수 있습니다.
Reading characteristics and descriptors is subject to the security permissions and the server can deny permission if the connection’s security level does not match the established requirements (see “Security” on page 72).
특성 및 설명자 읽기에는 보안 권한이 적용되며 연결의 보안 수준이 설정된 요구 사항과 일치하지 않는 경우 서버는 권한을 거부할 수 있습니다 (72페이지의 "보안" 참조).
Writing Characteristics and Descriptors
쓰기 특성 및 설명자
To write to the value of a characteristic value or a descriptor, the client has the following choices:
특성 값이나 설명자의 값을 쓰기 위해 클라이언트는 다음과 같은 선택 사항을 갖습니다.
Write characteristic value or descriptor
특성 값 또는 설명자를 쓰기
This feature is used to write to a characteristic value or descriptor.
이 기능은 특성 값이나 설명자에 쓰는 데 사용됩니다.
The client provides a handle and the contents of the value (up to ATT_MTU-3 bytes, because the handle and the ATT operation code are included in the packet with the data) and the server will acknowledge the write operation with a response.
클라이언트는 핸들과 값의 내용(최대 ATT_MTU-3바이트, 핸들과 ATT 작업 코드는 데이터와 함께 패킷에 포함되기 때문)을 제공하고 서버는 응답으로 쓰기 작업을 확인합니다.
Write long characteristic value or descriptor
긴 특성 값 또는 설명자 쓰기
Similar to the read long characteristic value or descriptor feature, this permits a client to write more than ATT_MTU-3ATT_MTU-3 bytes of data into a server’s characteristic value or descriptor.
긴 특성 값 또는 설명자 읽기 기능과 유사하게, 이 기능은 클라이언트가 ATT_MTU-3ATT_MTU-3바이트 이상의 데이터를 서버의 특성 값 또는 설명자에 쓸 수 있도록 허용합니다.
It works by queueing several prepare write operations, each of which includes an offset and the data itself, and then finally writing them all atomically with an execute write operation.
이는 각각 오프셋과 데이터 자체를 포함하는 여러 쓰기 준비 작업을 대기열에 넣은 다음 마지막으로 쓰기 실행 작업을 통해 원자적으로 모두 쓰는 방식으로 작동합니다.
Additionally, and only applicable for characteristic values, these features are available:
또한, 특성 값에만 적용되는 다음 기능을 사용할 수 있습니다:
This feature is the converse equivalent of notifications (detailed in “Server-Initiated Updates” on page 72) and uses Write Command packets.
이 기능은 알림 (72페이지의 "서버에서 시작하는 업데이트"에 자세히 설명)과 동일하며 쓰기 명령 패킷을 사용합니다.
Write Commands are unacknowledged packets that include a handle and a value, and they can be sent at any time and in any amount without any flow control mechanism kicking in (except of course for the native Link Layer flow control, since all traffic is subject to it).
쓰기 명령은 핸들과 값을 포함하는 승인되지 않은 패킷이며 흐름 제어 메커니즘이 시작되지 않고도 언제든지 원하는 양으로 보낼 수 있습니다 (네이티브 링크 계층 흐름 제어는 제외). 모든 트래픽이 이에 영향을 받기 때문입니다)..
The server is free to silently discard them if it cannot process them or if the attribute permissions prevent it from accepting it.
서버는 해당 항목을 처리할 수 없거나 속성 권한으로 인해 해당 항목을 수락할 수 없는 경우 자동으로 삭제할 수 있습니다.
The client will never know, but that is by mutual agreement.
클라이언트는 절대 알 수 없으나, 이는 상호 합의에 의한 것입니다.
The only way for the client to find out whether the value was written is to read it after the fact.
클라이언트가 값이 기록되었는지 여부를 알아내는 유일한 방법은 사실 이후에 값을 읽는 것입니다.
Reliable writes
신뢰할 수 있는 쓰기
Similar to the read multiple characteristic values feature, when a client wants to queue write operations to multiple characteristic values, it issues a final packet to commit the pending write operations and execute them.
다중 특성 값 읽기 기능과 유사하게 클라이언트가 쓰기 작업을 여러 특성 값에 대기열에 추가하려는 경우 최종 패킷을 발행하여 보류 중인 쓰기 작업을 커밋하고 실행합니다.
Writing characteristics and descriptors is subject to the security permissions, and the server can deny permission if the connection’s security level does not match the established requirements (see “Security” on page 72).
특성 및 설명자 쓰기에는 보안 권한이 적용되며, 연결의 보안 수준이 설정된 요구 사항과 일치하지 않는 경우 서버는 권한을 거부할 수 있습니다 (72페이지의 "보안" 참조).
Server-initiated updates are the only asynchronous (i.e., not as a response to a client’s request) packets that can flow from the server to the client.
서버 시작 업데이트는 서버에서 클라이언트로 흐를 수 있는 유일한 비동기 (클라이언트 요청에 대한 응답이 아닌) 패킷입니다.
These updates send timely alerts of changes in a characteristic value without the client having to regularly poll for them, saving both power and bandwidth.
이러한 업데이트는 클라이언트가 정기적으로 폴링할 필요 없이 특성 값의 변경 사항에 대한 적시에 경고를 보내 전력과 대역폭을 모두 절약합니다.
There are two types of server-initiated updates:
서버 시작 업데이트에는 두 가지 유형이 있습니다:
Characteristic Value Notification
특성 값 알림
Notifications are packets that include the handle of a characteristic value attribute along with its current value.
알림은 현재 값과 함께 특성 값 속성의 핸들을 포함하는 패킷입니다.
The client receives them and can choose to act upon them, but it sends no acknowledgement back to the server to confirm reception.
클라이언트는 이를 수신하고 이에 따라 조치를 취할 수 있지만 수신을 확인하기 위해 서버에 승인을 다시 보내지 않습니다.
Along with write without response, this is the only other packet that does not comply with the standard request/response flow control mechanism in ATT, as the server can send any number of these notifications at any time.
응답 없는 쓰기와 함께 이것은 ATT의 표준 요청/응답 흐름 제어 메커니즘을 준수하지 않는 유일한 다른 패킷입니다. 서버는 언제든지 이러한 알림을 원하는 만큼 보낼 수 있기 때문입니다.
This feature uses the handle value notification (HVN) ATT packet.
이 기능은 HVN (핸들 값 알림) ATT 패킷을 사용합니다.
Characteristic Value Indication
특성 값 표시
Indications, on the other hand, follow the same handle/value format but require an explicit acknowledgment from the client in the form of a confirmation.
반면, 표시는 동일한 핸들/값 형식을 따르지만 확인의 형태로 클라이언트의 명시적 승인이 필요합니다.
Note that although the server cannot send further indications (even for different characteristics) until it receives confirmation from the client (because this flows in the opposite direction than the usual request/response pairs), an outstanding confirmation does not affect potential requests that the client might send in the meantime.
서버는 클라이언트로부터 확인을 받기 전까지는 (다른 특성에 대한 것도 포함) 추가 표시를 보낼 수 없지만 (이는 일반적인 요청/응답 쌍과 반대 방향으로 흐르기 때문임), 아직 확인이 완료되지 않았더라도 그 사이에 클라이언트가 보낼 수 있는 잠재적 요청에는 영향을 미치지 않습니다.
This feature uses the handle value indication (HVI) and handle value confirmation (HVC) ATT packets.
이 기능은 HVI (핸들 값 표시) 및 HVC (핸들 값 확인) ATT 패킷을 사용합니다.
The client must enable both types of server-initiated updates by writing to the corresponding CCCD before the server can start sending them.
클라이언트는 서버가 업데이트 전송을 시작하기 전에 해당 CCCD에 기록하여 두 가지 유형의 서버 시작 업데이트를 모두 활성화해야 합니다.
“Client Characteristic Configuration Descriptor” on page 62 describes this process extensively.
62페이지의 "클라이언트 특성 구성 설명자"에서는 이 프로세스를 광범위하게 설명합니다.