5.8 Data exchange between Providers

Limax supports secure data exchange between trusted Providers through client-site tunneling, and the specific data content is interpreted by Provider itself.

---

• 5.8.1 Basic framework

  
  
  

  • Client-site tunneling

    The usual server-to-server data exchange needs to establish a network connection between servers, which is very different from the client-site tunneling mode. Here is a comparison.

    	Client-site tunneling	Server direct connection
    Large amounts of data	Not suitable	Suitable
    Server firewall	Not required	The more complex the network topology of the server, the complex the firewall. In the actual operating environment, the network and server belong to different departments. It is usually unrealistic to adjust the firewall configuration with server configuration, not to mention the cooperation of organizations.
    Server trust relationship	Implemented through the certificate	Also through the certificate, no implemented version
    Client data transfer	Simple. The client can perform instant transfer after connecting both servers. The client can also temporarily store data and perform non-instantaneous transfer.	Complex. It is a dilemma whether the server-to-server connection on demand or persistent. After all, the client needs to get involved in the coordination of the transmission process, which requires the complex process.

  
  

  • Data security

    1. Determine the trust domain by certificate, and the servers in the trusted domain can exchange data securely. Please refer the appendix "PKIX support" and "Key distribution system" for the detail.

    2. Data passing through the tunnel is encoded by external data. Please refer the appendix "External data" for the detail.

  
  

  • Data label

    1. The exchange process of tunnel data is an asynchronous process.

    2. The client and server (possibly all participanting servers) first perform the negotiation process, which results in a tunnel exchange Session. The complete understanding is that the lable is the Sessionid of a tunnel exchange process.

    3. Actually, the most applications do not need so complicated exchange behavior, and can reinterprete the label and simplify the application development. For example, mark the type of application data, and directly determine the ProviderID of the target, and so on.

---

• 5.8.2 Basic process of data exchange

  1. The client and server negotiate, decide the trusted domain, determine the data label, and package the application data on the server site. This step depends on the implementation of the application.

  2. The server sends data label and tunnel data.

  3. The client receives the data label and protected tunnel data, and forwards the data or forwards the data after temporarily storing according to the negotiation result.

  4. The server receiving data executes the asynchoronus callback with the data label and the decoded application data. The callback process depends on the implementation of the application.

---

• 5.8.3 Server development

  • Tunnel exception

    All kinds of exceptions may appear when tunnel operates, with limax.provider.TunnelException to represent. These exceptions are divided into 4 types and described by using the enumeration limax.provider.TunnelException.Type, respectively as

    1. NETWORK, exception appears when network operates.

    2. CODEC, encoding and decoding exception, this usually is that the data is tampered with.

    3. EXPIRE, the tunnel data expires. The source server encodes expire time into the protected data. The destination server verifies this expiration time with its own current time, and throws this exception when failing.

    4. LABEL, label exception. When the source server sends the label in plaintext, the label is also encoded into the protected data. If the label is modified when the client performs forwarding, this exception is thrown by the destination server when it verifies.

    TunnelException.getType() can get the type of exception. For NETWORK and CODEC type, the exception that causes the TunnelException can be obtained through TunnelException.getException().

  
  

  • Send data

    After completing the negotiation between the client and server, preparing the trust domain, data label and application data, the data can be sent through 4 optional methods.

    1. limax.provider.View.tunnel(long sessionid, java.net.URI group, int label, Octets data) throws TunnelException;

    2. limax.provider.View.tunnel(long sessionid, int label, Octets data) throws TunnelException;

    3. limax.provider.SessionView.tunnel(java.net.URI group, int label, Octets data) throws TunnelException;

    4. limax.provider.SessionView.tunnel(int label, Octets data) throws TunnelException;

    The first method is the basic version. The sessionid determines the clients participating in the tunnel, the group is the trusted domain (refer the appendix "Key distribution system"), the label is the data label, and the data is the application data. The SessionView has the sessionid of client, so the method of SessionView ommittes the sessionid parameter. The defaultGroup configured by server is used as trusted domain when calling default group method. Please refer the "Operation configuration" for the detail.

    The tunnel and View have no any relationship. The reason why the tunnel method is on the View is entirely for programming convenience. When Provider is programming, all operations should be completed on the View, including the negotiation process. After the negotiation is completed on the specific View and the parameter is prepared, the tunnel is directly executed on this View.

  
  

  • Receive data

    When Provider implements limax.provider.ProviderListener, it also implements limax.provider.TunnelSupport interface at the same time.

    
    

        public interface TunnelSupport {
            void onTunnel(long sessionid, int label, Octets data) throws Exception;
            default void onException(long sessionid, int label, TunnelException exception) throws Exception {
                throw exception;
            }
        }
        

    Implement the onTunnel method to receive the label and application data forwarded from client. The onTunnel method is dispatched on the thread corresponding to the sessionid, and calling the method associated to the same user is thread-safe.

    The process of decoding data may throw a TunnelException of CODEC, EXPIRE, or LABEL type. Such an exception can be caught through implementing onException method.

    The default onException method rethrows this exception, which causes the Provider to record the error log and use the error code ErrorCodes.PROVIDER_TUNNEL_EXCEPTION to close the connection with client.

  
  

  • Matters need to attention

    The Provider that does not support TunnelSupport also can send tunnel data. After receiving the tunnel data, such Provider records the error log, and use the error code ErrorCodes.PROVIDER_TUNNEL_EXCEPTION to close the connection with client.

Prev Next