Add RACv1.99.2 protocol specification

README.md

@@ -39,20 +39,26 @@ Once the server is running, clients can connect to it and send messages accordin
 
 1. Message Retrieval
 
-   a. The client initiates a message retrieval session by sending the byte 0x00 to the server.
+   a. The client initiates a message retrieval session by sending the byte `0x00` to the server.
 
    b. In response, the server transmits the size of the available messages as an ASCII-encoded string.
 
-   c. After receiving the size, the client must send the following byte or close the connection:
+   c. After receiving the size, the client must send one of the following bytes or close the connection:
 
-   i. Sending 0x01 instructs the server to transmit the messages.
+   i. Sending `0x01` instructs the server to transmit all messages in full.
+
+   ii. Sending `0x02` followed by the client’s cached messages length (as an ASCII string, e.g., `0x02"1024"`) instructs the server to transmit only new messages added since the cached length. The server sends messages starting from the cached length offset, and the client updates its cached length to the total size received in step 1b after processing the new messages.
 
 2. Message Transmission
 
    a. To send a message, the client issues a request in the following format:
 
-   0x01 followed immediately by the message content.
+   `0x01` followed immediately by the message content.
 
 ### Additional Notes:
 
-Although the protocol may appear similar to RACv1, it is important to note that RACv1.99 represents the beta development phase of RACv2. Consequently, significant changes and enhancements are anticipated. The current specification is implemented in lRACd version 1.99.1 and clRAC version 1.99.1.
+- Although the protocol may appear similar to RACv1, it is important to note that RACv1.99 represents the beta development phase of RACv2. Consequently, significant changes and enhancements are anticipated. The current specification is implemented in `lRACd` version 1.99.2 and `clRAC` version 1.99.2.
+
+- When using `0x02` for incremental retrieval, the client must ensure the cached length is synchronized with the server’s total message length (retrieved via `0x00`). The server sends messages from the cached length onward, and the client calculates the read size as `(total_length - cached_length)`.
+
+- After receiving incremental messages, the client must update its cached length to the total length provided in step 1b to maintain consistency in subsequent requests.

src/main/java/net/pixtaded/crab/server/Database.java

@@ -6,7 +6,7 @@ import net.pixtaded.crab.common.Sanitizer;
 import java.sql.*;
 import java.util.Date;
 
-public class Database implements AutoCloseable {
+public class Database {
 
     private Connection connection;
 
@@ -61,11 +61,4 @@ public class Database implements AutoCloseable {
         String logsString = s.toString();
         return new Logs(logsString.isEmpty() ? 0 : logsString.getBytes().length, logsString);
     }
-
-    @Override
-    public void close() throws SQLException {
-        if (connection != null && !connection.isClosed()) {
-            connection.close();
-        }
-    }
 }