Data flow sessionbase and Socketbase in ZeroMQ (Java)

The previous article has made it clear how Zeromq (Java) handles IO at the bottom,

The Selectablechannel object and the IO event callback are maintained through the Streamengine object, and then the selector object is maintained through the Poller object. Then use the Ioobject object to specifically manage Selectablechannel objects in the poller above the registration, as well as the event callback, the relationship between them can be described in the following diagram to a simple description:

For the received data, first handled by Streamengine, in fact, it will call the internal decoder to convert the byte data into a Msg object, and then to the upper object,

In fact, the upper object in this case is the session object, each Streamengine object has its own session object, and then the session object receives the following data, and then through the pipe, the data sent to its upper socket object,

Then the next data processing is referred to the user's code to deal with ...

For the level between the objects just mentioned, use the following graph to describe it:

This picture should be more direct, the bottom data Communication section is responsible for receiving data from the channel and sending binary data, and then decoder and encoder to take charge of the conversion between the byte data and msg ....

We will see many kinds of sockets in ZMQ, such as Req,dealer,router, they all inherit from the Socketbase type, each type has its own session, all inherit from the Sessionbase type ...

Well, then let's take a look at the sessionbase type, each Streamengine object has a session object associated with it, they are a one-to-ones relationship, first look at some of its important attribute definitions:

[Java]View Plaincopy

2. private Boolean connect; If a connection is required, if it is fasle, then it is the connection created by listener
6. private pipe pipe; The pipe that communicates with the socket
8. Private final set<pipe> terminating_pipes;
10. If true, there is also a message that is not executed in the pipe.
12. Private Boolean incomplete_in;
16. If true, means stop sending data to the network
18. Private Boolean pending;
22. Private Iengine engine; Bound to the bottom of the session above the communication
26. Private socketbase socket; The socket that the current session belongs to
32. Private Iothread Io_thread; The IO thread associated with the current session, and the underlying IO will be added to this IO thread
34. private static int linger_timer_id = 0x20;
38. True is linger timer is running.
40. Private Boolean Has_linger_timer; Have a timeout event registered?
42. Private Boolean identity_sent; If true, indicates that the flag has been sent
44. Private Boolean identity_received; Indicates that the flag has been received
46. Private final Address addr; The address of the connection
50. Private Ioobject Io_object; Associated IO object, Io object in Iengine

Specifically these attributes are what, the above comments are basically already given, here is the more important properties are:

Pipe, which is used to communicate with the above socket, when the underlying data is parsed out, will be through the pipe to send msg to the upper socket, concrete pipe process, the previous article has said ...

Iengine, the reference to the Streamengine object of the underlying data communication, this importance is not said, ...

Iothread object, this is the IO thread that the current session object will depend on, that is, the command sent to the session is received by the mailbox of the IO thread, which executes the command in this thread, um ... It's important ...

There are also some sign-bits or something ...

Well, let's not go into detail here, and take a look at some important ways:

[Java]View Plaincopy

1. In relation to pipe, this is basically to set the current pipe's event callback to the current object
2. public void Attach_pipe (pipe pipe_) {
3. ASSERT (!is_terminating ());
4. ASSERT (pipe = = null);
5. ASSERT (Pipe_! = null);
6. pipe = Pipe_; Save the current pipe
7. Pipe.set_event_sink (this); Sets the current pipe's event callback to the current
8. }

For associating pipe objects, you can see that the event of the pipe is returned to the current session object. So let's see how these events are handled by the callback method:

[Java]View Plaincopy

2. When there is data to the current pipe, in fact, the pipe opposite the socket to send the data here, and then send a pipe readable command, then indicate that there is data to be sent through the underlying engine
4. public void read_activated (Pipe pipe_) {
6. Skip activating if we ' re detaching this pipe
8. if (pipe! = pipe_) {
10. ASSERT (Terminating_pipes.contains (pipe_));
12. Return
14. }
18. if (engine! = NULL)
20. Engine.activate_out (); Activates the write event for the channel of the underlying engine
22. Else
24. Pipe.check_read ();
26. }
30. Indicates that the data can be sent to the pipe, which means it needs to receive the data from the underlying engine.
32. public void write_activated (Pipe pipe_) {
34. Skip activating if we ' re detaching this pipe
36. if (pipe! = pipe_) {
38. ASSERT (Terminating_pipes.contains (pipe_));
40. Return
42. }
48. if (engine! = NULL)
50. Engine.activate_in (); Activates the Read event above the channel of the underlying engin, i.e. notifies the underlying engin that the data should be received from the network
52. }

Here first the pipe can read the event callback method, this processing is very simple, direct activation of the underlying Streamengine Channle on the Poller register write events, then when the underlying channel can write data, Will read the data from the pipe in the current session and send it out.

The second method is when the pipe can be written, this is actually directly register the channel read event, then when the channel will be to receive data, and finally they will be sent through the pipe to the upper socket object ... The entire operation of the graph above should be clear ...

Then the most critical part of the session is almost there ... There are some details, after the need to introduce it ...

All right, let's take a look at socketbase. This type, the front has already said that all the socket types in ZMQ inherit from this type, visible his importance ... Let's take a look at some of its important attribute definitions:

[Java]View Plaincopy

2. Private final map<string, own> endpoints; Here to save all open endpoint, where key is the connection address, value is actually the session object
4. Private final map<string, pipe> Inprocs; IPC Communication Methods
8. Used to check whether the object is a socket.
10. private int tag; Flag bit that determines whether the current object is a socket type
14. Private Boolean ctx_terminated; If true, indicates that the associated context has stopped
18. Private Boolean destroyed; If true, indicates that the current socket object has been destroyed by the command.
20. Private final Mailbox Mailbox; A mailbox for receiving commands sent from somewhere else.
22. Private final list<pipe> pipes; All currently associated pipes, which are used for data communication with all sessions of the current socket.
24. Private Poller Poller; Poller Object
26. Private Selectablechannel handle; This is mailbox's handler.
28. Private long LAST_TSC; Last time the command was executed
30. private int ticks; The message received after the last command was executed
32. Private Boolean Rcvmore; And then there's a message to receive
34. Private Socketbase Monitor_socket; Socket for monitoring
36. private int monitor_events;
38. protected valuereference<integer> errno;

Here are some of the more important:

Enpoints, which is used to save all sessions with their connected addresses,

Pipes, save all the pipe associated with the underlying session, where the relationship between the socket and sesssion is one-to-many ...

Mailbox,socket also has its own mailbox, not attached to the Iothread object, but there is a pit, socket type object has its own mailbox, not dependent on the IO thread, does not mean that it has its own thread, because it directly depends on the user thread , depends on the user code ... In other words, the execution of the commands inside the mailbox is done in the user thread ... Oh, just started this place also tangled for a long time ...

Let's take a look at the event callback for its pipe:

[Java]View Plaincopy

1.     //the callback method that needs to be executed when the pipe is readable. Indicates that the underlying streamengin has data sent here   
2.     public  void read_activated  (Pipe pipe_)   {  
4. &NBSP;&NBSP;&NBSP;&NBSP;}&NBSP;&NBSP;
5. &NBSP;&NBSP;
6. //the callback to execute when the pipe can be written   
7.     public void write_activated  (Pipe  Pipe_)  {  
8.          xwrite_activated  (pipe_);   
9.     }   

In fact, there is not much content, because it is done in the specific subclass, but to here the whole zeromq (Java) How the data flow, even if it is clear ... Of course, there are some details that are not listed.

Well, so far, ZeroMQ (Java) is still the specific socket type of operation and encoding method of two large places without analysis ...

Data flow sessionbase and Socketbase in ZeroMQ (Java)