Zap is structured as a client-server model. The client unidirectionally sends data, and the server receives and processes it. This architecture keeps Zap's design simple and naturally allows a 1:N structure where multiple clients can send data to a single server.
+
A data sent from the client to the server is transmitted over UDP socket. Zap is implemented to send this data by defining 'ZAPP Object' defined on top of datagram, which contain the timestamp, resource type, and the actual data. ZAPP Object is the data unit of ZAPP(Zap Protocol), for more detailed information about the protocol, please check the ZAPP page.
+Zap uses callback functions to enable the transformation of a single-device application into a multi-device application while maintaining its own structure. The client, after obtaining the data they wish to transmit through the data source access API provided by their development framework, simply needs to call zap.send(...). The server, running a Zap server instance, only needs to define callback functions to specify what code to execute each time it receives data from the client.
The project structure is straightforward. Under the root, there are four main modules: ZapClient, ZapServer, Models, and Resources.
Models include interfaces and type definitions generally referenced throughout the Zap system. On the other hand, Resources consist of implementations of Zapable that can be transmitted via Zap. For example, ZapAccelerometer is a Zapable implementation representing accelerometer data. These resource implementations are referenced to abstract the data obtained from data sources in ZapClient or ZapServer and are encapsulated in ZappObject for network transmission. For more detailed information on each component, please read the Specifications section.
Zap defines a new network protocol over UDP to facilitate data exchange in an agreed-upon format across various platforms. This protocol is referred to as ZAPP(Zap Protocol), and the ZAPP data contained in a single datagram is called a 'ZAPP Object'.
+The ZAPP Object is divided into two main parts: the header and the payload. The header contains metadata about the ZAPP Object, while the payload represents the actual data of interest to the communicating parties.
+
The header consists of a timestamp and a resource field. The first 64 bits of the header constitute the timestamp field, representing the epoch time in milliseconds when the ZAPP Object was created. As UDP does not guarantee the order of datagrams, this field can be utilized if the order of data is crucial. This field can be interpreted as an unsigned integer.
+Following the timestamp, the next 8 bits constitute the resource field. The resource field informs which resource the payload represents and simultaneously implies how the payload is encoded. This field can be interpreted as an unsigned integer.
+After the 72-bit header, there is the payload part. The format of the payload varies depending on the resource. It can be a simple primitive type, text with delimiters, or JSON. Refer to the Resources page for information on the payload format each resource takes. The maximum length of the payload is theoretically up to 65,518 bytes, although it may vary depending on the implementation of Zap server.
+ + + + + + +