Netty in Action (24) 13th section UDP broadcast Events

The contents of this chapter include:

1) Overview of UDP

2) A simple example of a broadcast application

So far, all of the examples we have used are protocol-based protocols, such as TCP, in which we will focus on protocols without connection X (User Datagram Protocol UDP), This protocol is often used in situations where performance requirements are extremely high but allow a small amount of packet loss

Let's start with the concept of UDP, explain its features and limitations, and then we'll describe the business context of this chapter's example application, which will show you how to use the broadcast features of the UDP protocol, and we'll also use decoders and encoders to process a pojo, in the last part of this section, You should be able to use the UDP protocol to apply to your project

13.1 UDP Basics

Connection-based transport services such as TCP, a type of protocol that manages the connections established between the two terminals, the information can be ordered and trusted for transmission over the lifetime of the connection, and the terminal can be closed in an orderly manner when the connection is interrupted, instead of a non-connected protocol such as UDP, which is not a robust connection, Each information is a separate transmission body.

There is UDP does not exist in the TCP protocol error correction mechanism, this mechanism refers to each terminal when it receives a message packet, will give a feedback, not to return the package, the sender will resend

In contrast, a TCP connection is like a telephone communication, in which the information can be ordered in two terminals, instead, UDP is like a bunch of postcards in the mailbox, you can not know that they arrived in the order of the mailbox, and even do not know whether all the postcards have been all received

Because these limitations of these UDP protocols may limit you, it is also good to explain why UDP is faster than TCP, performance loss in the handshake phase, and message management are eliminated, and it is clear that UDP is a good choice for systems that can accept part of the loss of the message. Of course, this agreement is not applicable to the transmission of financial information

13.2 UDP Broadcast

The transmission mode we have used so far is called "single point Propagation", and the definition of single point propagation is that the message is sent only to a network destination confirmed by a unique address, which can be supported by two protocols with links and no connections, and UDP provides additional transport modes for sending messages to multiple recipients

1) Multicast (multicast)----------transferred to a defined set of terminals

2) Broadcast (broadcast)--------------transferred to all hosts in the entire network

In our example application in this chapter, we illustrate the broadcast mechanism of UDP by sending information to all hosts on the same network, for this purpose, We will use a special restricted broadcast 0-point network address 255.255.255.255, which will be transmitted to this address, which will be the address of all hosts on the local network and will not be forwarded to other networks by the router

Next we will discuss the design of this application

13.3 The UDP sample application

Our sample app will open a file and then broadcast each line of the file as a message on a specific port specified by UDP, and if you're familiar with Linux-like operating systems, you can think of this business scenario as a simplified version of Syslog functionality, Then UDP is suitable for such a scenario, because the occasional line loss of the journal file is completely acceptable, the given file is stored in the file system, and it provides a very valuable and efficient solution to large data transfer

So what about the recipient's settings? If you use UDP broadcast mechanism, then you can create an event manager to receive the diary information, we can simply start a listener, the program on a specific port to listen, note that this too easy access can cause potential security problems, This is one of the reasons why the UDP protocol is not used in insecure environments, because for the same reason routers often block the broadcast of information, restricting them only in the network segments where they originated

Publish/Subscribe: Applications like Syslig are a typical "publish subscription" type of system, a producer or a service publishing event, multiple clients subscribing to the event and then receiving their

Figure 13.1 shows a view of the application system, which contains a broadcast of one or more event managers, the broadcast monitoring whether there is a new content, if it appears, it is used as a broadcast message with the UDP protocol to spread out

All the time the manager listens to the UDP port to receive the broadcast information

In order to keep our example as simple as possible, we will not be authorizing, validating, encrypting these components into our simple application, but this does not mean that it is difficult to mix these features together, and that combining these components is simple for netty, and these components can increase the robustness of the application, usability

In the next section, we'll start exploring the design and implementation details of broadcast components

13.4 The message Pojo:logevent

In the message application, the data is often represented by a pojo, which contains some configuration information or some processing information and even some real information, in this application, we treat the information as an event, because the data is from the journal file, so we name it " LogEvent ", the code listing shows the details of this Pojo

We have defined the message component, we can implement the logic of the broadcast of the application system, and in the next chapter we will learn some of the classes provided by the Netty framework that can be used to encode and transmit the LogEvent message object

13.5 Writing the broadcaster

Netty provides a number of classes to support UDP application code writing, and we mainly use several classes that are message containers and channel types, which I have listed in 13.1:

Netty's Datagrampacket is a simple information container, and then using the concrete implementation of Datagramchannel can be very convenient for terminal communication, as we mentioned before, we give examples of postcards, This postcard contains the address of the recipient and may have the sender's address, as well as some information that the information itself carries

In order to convert EventLog information into datagrampackets, we need an encoder, and of course we don't have to write from scratch, and we can use the Messagetomessageencoder introduced in chapters Nineth and tenth to help us do this.

Figure 13.2 shows the broadcast of three log objects, each of which has their own corresponding proprietary Datagrampacket

Figure 13.3 shows a high level diagram of Logeventbroadcaster's channelpipeline, showing how logevent flows inside.

You can see that all the data is encapsulated in a logevent message format for transmission, Logeventbroadcaster writes LogEvent to the channel and sends it through the pipeline, before These messages may be encoded into a DATAGRAMPACKET message format to propagate, and eventually they will be broadcast by UDP and finally be retrieved by the terminal

The following code listing shows our custom messagetomessageencoder, which will complete the features we discussed earlier

With the implementation of Logeventencoder, we are now ready to start the server, the server needs to set some startup parameters, and need to install some required channelhandler into the pipeline, which will be done by Logeventbroadcaster method , as shown in the following code listing:

This completes the broadcast component of your application, the beginning of the test, you can use Netcat, on the unix/linux system you can find the NC software installation, Windows version download can be downloaded in Http://nmap.org/ncat

Netcat is very suitable for a software most basic test, it does the thing is very simple: listen on a certain port, print out all the data received by this port, in our project we can set the following command to listen to UDP data on port 9999

Now we need to start our logeventbroadcaster, the following startup diary shows how to use MVN to compile and then run the broadcaster, the file specified in Pom.xml is often changed, adding the path to the setup file in the Linux environment is "/var/ Log/messages/"and set the port number to 9999, then this file will receive the broadcast information via UDP broadcast, and then when we start netcat, we can record all the information of all the console outputs.

If you want to change the output path and port number of the file, we can re-specify the value in the form of a system variable when running the MVN command, and the following journal output shows how to reset the log path and port number.

When you see in the diary information Logeventbroadcaster can run normally, you can confirm that it has been successfully started, if there is an error, then the error message will be printed, a wrong message will be printed, once the process is running, It will broadcast each log message and add it to the log file.

Using Netcat is a good fit for our application, but it is not very suitable for systems that are applied to production environments, for this reason we need to develop the second module of our application, the broadcast monitor, the next section, and we will implement this function

13.6 Writing the Monitor

Our goal is to replace Netcat with a more complete event consumer, the new function we call Eventlogmonitor, the function of this program is:

1) Datagrampakets of UDP receiving Logeventbroadcaster broadcast

2) decode the received message into a logevent message

3) Print the decoded logevent with System.out

As we did before, the business logic block for the monitoring application was done by our custom four decoders, and we inherited the Messagetomessagedecoder, Figure 13.4 depicts the channelpipeline of Logeventmonitor and shows how logevent through this pipeline

The first decoder in this pipeline is Logeventdecoder, which is responsible for converting its input datagrampackets into LogEvent messages, This is a typical setup for all Netty applications, starting with the conversion of the input information, the following code listing gives the implementation

The role of the second channelhandler is to do some processing of the LogEvent message created by the first channel, and in our simple case we simply print it out, possibly in a real production environment, You might aggregate the diaries of different data sources and store the aggregated results in a database, and the following code listing shows how Logeventhandler can accomplish this task.

Logeventhandler will print out logevent information in a more readable way, including the information printed

1) The time stamp received

2) Sender's inetsocketaddres, which includes IP and port number

3) Absolute path name generated by the LogEvent file

4) Real diary information, including a full line of diary output

Now that we have our processor installed in the Channelpipeline, as shown in Figure 13.4, this work will be done by our Logeventmonitor main function

13.7 Running the Logeventbroadcaster and Logeventmonitor

As we did before, we used MAVEN to run our program, but this time we need to open two running Windows, two to run the program, each to keep running, to know you use CTRL + C to build a stop program

First, you need to start logeventbroadcaste, because we've already built this app before, so the following command is sufficient:

From now on, it will start broadcasting diary messages via UDP.

Now open a new window, build and launch Logeventmonitor to receive and display the broadcast message:

When you see Logeventmonitor running, you will realize that the application has run successfully, and if there are any errors, the exception information will be printed on the console.

The console will show all the events, as shown in the following diary, all of the information formats are created by the Logeventhandler specification

If you can't get a diary of UNIX, you can create a custom file to manually apply it to your app, the following command shows how to use this file, first create an empty file

We will now start restarting Logeventbroadcaster, pointing to the file we just created by system variables

Once Logeventbroadcaster is up and running, you can manually add information to the file you just created, and then you can see the broadcast information in the logeventmonitor console and output it to a file using echo redirection:

You can create as many monitoring instances as you like, each of which will receive the same information printed

13.8 Summary

In this chapter, we explain the non-connected protocol such as UDP, we build a simple project example, we will broadcast the diary information in the form of UDP datagrams to each subscriber, this example tells us how to use the Netty UDP, And UDP can be used in some of the more special scenarios have some unique

In the next two chapters, we'll be fortunate to see how developers from world-class companies are using Netty to build industrial-grade applications.

Netty in Action (24) 13th section UDP broadcast Events