A Weosocket Communication server and client code (non-JS code) based on Netty

A Weosocket Communication server and client code (non-JS code) based on Netty

Cough, here, little Xuan is not much to say what is websocket, there is, small Xuan Why do not give js-client code? Too much code can be used on the Internet. Small Xuan Here the WebSocket client is non-JS client, because the small Xuan project background logic to communicate with the WebSocket server, so just got a client out. Not much to say, first on the results chart.

1. Start the WebSocket server

1. Startup Project (client 1)

1. Using the WS-JS client to establish a connection to the server (client 2)

1. Invokes the project interface, which sends a message to client 2 by client 1.

Here, the small Xuan can support text message, also can support the binary data. Of course, the logic is simple to write, simply send a message. However, the business logic can be modified on this basis to meet their business requirements.

Well, the picture, first here, the small Xuan side has been in normal use. No video presentation is really flawed.

The reason to see Tdg_yyx is different from the connection, because the system prefix is added to the integrated client in the small Xuan project. That's why there's a demo chart. Of course, if you want to know how to use the specific, you can still contact Xiao Xuan I oh.

The encoding and decoding data in the example is the use of Msgpack to serialize an object. However, a text message is used when sending the server to the browser client.

The project source has been shared to GitHub, and a new repository has been started. Separated from the previous demo. Can be directly taken down to modify the OH.

Directory structure

|-Xpush

|--push-client

| ———— org.yyx.message.push.client

| —————— client Code

| —————— Config//load the configured Netty configuration class package from the Yml file

| —————— entity class package for the transfer between server and client

| —————— handler//WebSocket Client processing Package

| —————— Listener//listener to start the client

| —————— util//The interface should be written here, primarily for the logic of transmitting messages

| ———— pushclientapplication//Springboot startup class

|--push-server

| ———— org.yyx.message.push.server

| —————— Config//load the configured Netty configuration class package from the Yml file

| —————— entity class package for the transfer between server and client

| —————— handler//WebSocket service-side processing package

| —————— Listener//WebSocket service-side listener

| —————— main//service-side code

| —————— util//The interface should be written here, primarily for the logic of transmitting messages

| ———— Serverapplication.java//Springboot startup class

Processing of the service side

1. Websocketurl is Ws://localhost:9999/oa/web_socket/{uri} where {URI} is used to receive business parameters
2. If the message received by the server is a text message, the content returned to the client is: The message you sent is: + Original message content
3. In the case of binary data, it is decoded and the codec is using the Messagepack tool. If you want to develop your own business logic, you can extract the handlerwebsocketframe method into the interface and take your business logic according to different business. In the source code, the server and the client use the same entity class. For simple point-to-point communication. See websocketmessageentity entity classes.

Client-side processing

1. In the source code, the client connects to the local server, and the connection is successful after WebSocket communication. The URL is: ws://127.0.0.1:9999/web_socket/${username} where UserName is the user name. That's my own business parameters.
2. Once the connection is successful, the username channel is retained. When a message needs to be sent to the server, the channel to which it is connected is obtained according to the user name, and the message is transmitted.
3. Now the client's processing logic is to send binary data that specifies which client the server sends the message to. If you have your own business logic, you can modify it according to the service-side business.

Test Cases

1. Start the service side.
2. Integrate client code into existing projects (here I'm integrating a Tomcat application server-based Web project)
3. Start the client (here, I communicate the project to the server as a user system_manage)
4. Through the landing portal of the Web project, a user is connected with the server (the front-end page in the project, using JS to communicate directly with the server, but the trigger point is after the landing system)
5. User A sends a message to User B

So far, you still don't see the role of the client. No hurry, look down.

When the Web server handles some business, need to send a message to the current user a push, you can call the client directly in the background to send a message to the user's method, at this time, the client is used.

The Web backend calls the client to send a message to the specified user in the System_manage identity mentioned above. Message to the service side of the binary data, the server has written business logic, the message decoded, write back to User A (yes, User A is through JS and the server to establish the connection of the front-end users) Of course, here can also be done to the online users to send messages. There's not much to say here. The principle is the same.

Project Source

Blog path

Contact information

A Weosocket Communication server and client code (non-JS code) based on Netty