Java WebSocket life cycle

This chapter describes the life cycle of the websocket endpoint. The lifecycle of the WebSocket endpoint provides the developer with a framework to manage the resources needed for the endpoint, as well as a framework to intercept messages. We'll look at the sequence and semantics of their lifecycle, and how the Java WebSocket API provides APIs and annotations to support handling these events.

First, the WebSocket agreement

Unlike HTTP-based technologies, WebSocket has a life cycle. This lifecycle cycle is supported by the WebSocket protocol. The WebSocket protocol defines a dedicated TCP connection for a long time between the client and the server, and once the connection has been established, the data can be transferred back and forth. The WebSocket protocol contains two main types of frames: control frames and data frames. A control frame is a data transfer that is used to perform some internal logic for the protocol. For example, close the frame (meaning the sender is ready to close the connection), Ping the frame (check the health of the WebSocket peer node's connection). Pong frame (responds to ping frames). The data frame defines the kind of websocket transmission that carries the application data. Data frames are divided into two categories: text and binary (for example, image data).

Second, WebSocket life cycle

The first event of all Java WebSocket endpoint lifecycles is an open notification, which indicates that a connection to the other end of the WebSocket session has been established. Once an open notification is received at both ends of the websocket conversation, any websocket that participates will be able to send the message later. During the WebSocket conversation, some message-passing errors may occur. The WebSocket endpoint that accepts the message itself may produce an error, or the WebSocket implementation itself will produce an error in some cases. Be aware of the handling of errors. No matter which end of the websocket conversation is ready to end the conversation, he can initialize the Shutdown event. Here's a look at how the life cycle is presented from the perspective of the Java component.

• Open Event: @onopen This event occurs when a new connection is established on the endpoint and before any other events occur

• Message Event: @OnMessage This event to receive messages sent at the other end of the websocket conversation.

• Error Event: @OnError This event occurs when an WebSocket connection or an endpoint error occurred

• Shutdown Event: @OnClose This event indicates that the connection to the WebSocket endpoint is currently partially closed, which can be emitted by any of the endpoints participating in the connection

As you may have noticed, I use annotations to illustrate endpoint event handling, which is what WebSocket recommends. Although, you can also use an inheritance to program these events

2. @OnOpen indicates that this method is called when this endpoint establishes a new connection. This event is accompanied by three pieces of information: The WebSocket Session object, which is used to represent an already established connection, a configuration object (an instance of Endpointconfig) that contains information to configure the endpoint, a set of path parameters, Used to open the stage handshake when the WebSocket endpoint inbound match URI. @OnOpen annotations are public methods that do not have any return values, which have an optional session parameter, an optional endpointconfig parameter, and any number of string arguments that are @pathparam annotations.

4. @OnMessage inbound messages are processed. As explained in the Java Training organization , the messages on the connection will arrive in 3 basic forms: Text messages, binary messages, or pong messages. The most basic form is the choice of using a method with string parameters to handle text messages, or a method that uses Bytebuffer or byte[] parameters to process binary text, and if your message is simply to process pong messages, you can use Java WebSocket An instance of the Pongmessage interface in the API. Of course, you can use a Boolean parameter to represent the shards of incoming messages. When the Boolean parameter value is False, the subsequent addition of the entire text message sequence to the arrival of more message shards, when set to True, indicates that the current message is the last shard in the message shard. There are many options for handling messages, such as using JAVAI/O, which can even allow WebSocket to convert inbound messages into objects of their choice. This will be mentioned in the Message Communication Foundation, where websocket applications are generally asynchronous bidirectional messages. So there is an extra option on this type of method that is annotated by @onmessage: The method can have a return value or return to NULL. When a method with @onmessage annotations has a return type, the WebSocket implementation immediately returns the return value as a message to the sender of the message that has just been processed in the method.

6. @OnError can handle any exceptions that occur when the WebSocket implementation processes inbound messages. The basic error type in 3 may occur when processing inbound messages. First, the errors that are generated by the WebSocket implementation may occur, these exceptions belong to the Sessionexception type, and secondly, the error may occur when the WebSocket implementation attempts to decode the inbound message into the object required by the developer. Such errors are decodeexception types. Finally, run-time errors are generated by other methods of the WebSocket endpoint. The WebSocket implementation will record any exceptions that occur during the WebSocket endpoint operation.

8. @OnClose it to do other general cleanup work when the WebSocket connection is closed. @OnClose can be used to annotate several different types of methods to close an event.

Java websocket life cycle