Ouroboros Tutorial 01 - Revision history

Thijs: Use long form command line options in documentation & tutorials.

2023-11-30T12:00:25Z

Use long form command line options in documentation & tutorials.

← Older revision		Revision as of 12:00, 30 November 2023
Line 63:		Line 63:

	<syntaxhighlight>		<syntaxhighlight>
	$ oping --server-name oping-server --count 5 #short form: oping -n oping-server -c 5		$ oping --server-name oping-server --count 5 #short form: oping -n oping-server -c 5
	Pinging oping-server with 64 bytes of data (5 packets):		Pinging oping-server with 64 bytes of data (5 packets):

Thijs: Use long form command line options in documentation & tutorials.

2023-11-30T11:58:52Z

Use long form command line options in documentation & tutorials.

← Older revision		Revision as of 11:58, 30 November 2023
Line 63:		Line 63:

	<syntaxhighlight>		<syntaxhighlight>
	$ oping -n oping-server -c 5		$ oping --server-name oping-server --count 5 #short form: oping -n oping-server -c 5
	Pinging oping-server with 64 bytes of data (5 packets):		Pinging oping-server with 64 bytes of data (5 packets):

Dimitri at 12:01, 5 November 2023

2023-11-05T12:01:44Z

← Older revision		Revision as of 12:01, 5 November 2023
Line 134:		Line 134:
	The first 3 lines show the deallocation by the oping client, lines 4-6 the deallocation of the client side flow endpoint by the IPCP. Line 7 shows the client process (5836) has exited. After a few seconds, the flow will also time out at the server side, and then the logs in the IRMd show the deallocation initiated by the oping server (lines 8-10) and finished up by the ipcp (lines 11-14).		The first 3 lines show the deallocation by the oping client, lines 4-6 the deallocation of the client side flow endpoint by the IPCP. Line 7 shows the client process (5836) has exited. After a few seconds, the flow will also time out at the server side, and then the logs in the IRMd show the deallocation initiated by the oping server (lines 8-10) and finished up by the ipcp (lines 11-14).

	This concludes this first short tutorial. All running processes can be terminated by issuing a Ctrl-C command in their respective terminals ~~or you can continue with the next tutorial~~.		This concludes this first short tutorial. All running processes can be terminated by issuing a Ctrl-C command in their respective terminals.

Dimitri at 11:59, 5 November 2023

2023-11-05T11:59:17Z

← Older revision		Revision as of 11:59, 5 November 2023
Line 3:		Line 3:
	The description of this tutorial uses a [[Ouroboros Build Parameters\|debug build]].		The description of this tutorial uses a [[Ouroboros Build Parameters\|debug build]].

	We will start the IRMd, create a local ~~IPCP~~, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.		We will start the IRMd, create a local Layer, start a ping server and connect a client to send a few pings. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.

	We recommend to open multiple terminal windows for this tutorial. In the first window, start the IRMd (as a superuser) in stdout mode. The output shows the process id (pid) of the IRMd, which will be different on your machine.		We recommend to open multiple terminal windows for this tutorial. In the first window, start the IRMd (as a superuser) in stdout mode. The output shows the process id (pid) of the IRMd, which will be different on your machine.

Dimitri at 11:52, 5 November 2023

2023-11-05T11:52:42Z

← Older revision		Revision as of 11:52, 5 November 2023
Line 1:		Line 1:
	[[File: O7s_tutorial01-01.png\|border\|right\|thumb\|frame\|Ouroboros tutorial 01]]		[[File: O7s_tutorial01-01.png\|border\|right\|thumb\|frame\|Ouroboros tutorial 01]]

	The description of this tutorial uses a [[Ouroboros Build ~~Options~~\|debug build]].		The description of this tutorial uses a [[Ouroboros Build Parameters\|debug build]].

	We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.		We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.

Dimitri at 11:52, 5 November 2023

2023-11-05T11:52:11Z

← Older revision		Revision as of 11:52, 5 November 2023
Line 1:		Line 1:
	[[File: O7s_tutorial01-01.png\|border\|right\|thumb\|frame\|Ouroboros tutorial 01]]		[[File: O7s_tutorial01-01.png\|border\|right\|thumb\|frame\|Ouroboros tutorial 01]]

			The description of this tutorial uses a [[Ouroboros Build Options\|debug build]].

	We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.		We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.

Dimitri at 11:47, 5 November 2023

2023-11-05T11:47:50Z

← Older revision		Revision as of 11:47, 5 November 2023
Line 3:		Line 3:
	We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.		We will start the IRMd, create a local IPCP, start a ping server and connect a client. This will involve binding (1) that server application to a name and registering (2) that name into the local layer. After that, the client will be able to allocate a flow (3) to that name for which the server will respond.

	We recommend to open 3 terminal windows for this tutorial. In the first window, start the IRMd (as a superuser) in stdout mode. The output shows the process id (pid) of the IRMd, which will be different on your machine.		We recommend to open multiple terminal windows for this tutorial. In the first window, start the IRMd (as a superuser) in stdout mode. The output shows the process id (pid) of the IRMd, which will be different on your machine.

	<syntaxhighlight>		<syntaxhighlight>
Line 32:		Line 32:
	</syntaxhighlight>		</syntaxhighlight>

	The IRMd will notice that an oping server (in our case with pid 6810) has started, but there are no service names bound to it yet:		The IRMd will notice that an oping server (in our case with pid 6810) has started, but there are no service names bound to it yet, as shown in the (debug-level) log output:

	<syntaxhighlight>		<syntaxhighlight>

Dimitri at 11:37, 5 November 2023

2023-11-05T11:37:08Z

Show changes

Dimitri at 11:28, 5 November 2023

2023-11-05T11:28:40Z

← Older revision		Revision as of 11:28, 5 November 2023
Line 79:		Line 79:
	<syntaxhighlight>		<syntaxhighlight>
	New flow 64.		New flow 64.
			Received 64 bytes on fd 64.
	Received 64 bytes on fd 64.		Received 64 bytes on fd 64.
	Received 64 bytes on fd 64.		Received 64 bytes on fd 64.

Dimitri at 11:26, 5 November 2023

2023-11-05T11:26:05Z

← Older revision		Revision as of 11:26, 5 November 2023
Line 105:		Line 105:
	</syntaxhighlight>		</syntaxhighlight>

	First, the IPCPd shows that it will allocate a flow towards a destination hash ~~“4721372d”~~ (truncated). The IRMd logs that IPCPd ~~2324~~ (our local IPCPd) requests a flow towards any process that is listening for ~~“4721372d”~~, and resolves it to ~~“oping_server”~~, as that is a process that is bound to that name. At this point, the local IPCPd has a pending flow on the client side. Since this is ~~the~~ first ~~port_id~~ in the system, it has ~~port_id~~ 0. The server will accept the flow and the other end of the flow gets ~~port_id~~ 1. The local IPCPd sees that the flow allocation is completed. Internally it sees the endpoints as flow descriptors 64 and 65 which map to ~~port_id~~ 0 and ~~port_id~~ 1. The IPCP cannot directly access ~~port_ids~~, they are assigned and managed by the IRMd. After it has accepted the flow, the oping server enters flow_accept() again. The IRMd notices the instance and reports that it accepts flows for ~~“oping_server”~~.		First, the IPCPd 5843 shows that it will allocate a flow towards a destination hash “f6c93ff2” (truncated) and this flow has flow descriptor (''fd'') 64. The IRMd logs that IPCPd 5843 (our local IPCPd) requests a flow towards any process that is listening for “f6c93ff2”, and resolves it to “oping-server”, as that is a process that we bound to that name. At this point, the local IPCPd has a pending flow on the client side on ''fd 64''. Since this is our first flow_id in the system, it has flow_id 0. The server will accept the flow and the other end of the flow gets flow_id 1. The local IPCPd sees that the flow allocation is completed. Internally it sees the endpoints as flow descriptors 64 and 65 which map to flow_id 0 and flow_id 1 respectively. The IPCP cannot directly access flow_ids, they are assigned and managed by the IRMd. After it has accepted the flow, the oping server enters flow_accept() again. The IRMd notices the instance and reports that it accepts flows for “oping-server”.

	~~After all packets have been sent, the client will exit and deallocate the flow. The process can also be seen in the IRMd output:~~

			After all packets have been sent, the oping client (process 5929) deallocates the flow and exits. This process can also be seen in the IRMd/IPCP log output:
	<syntaxhighlight>		<syntaxhighlight>
	==05813== irmd(DB): Deallocating flow 0 for process 5929.		==05813== irmd(DB): Deallocating flow 0 for process 5929.
Line 126:		Line 125:
	==05843== ipcpd/ipcp(II): Finished deallocating flow 1: 0.		==05843== ipcpd/ipcp(II): Finished deallocating flow 1: 0.
	</syntaxhighlight>		</syntaxhighlight>

			Deallocation is a two-phase process at each side of the flow, it is initiated by the client process and finalized by the IPCP.
			The first 3 lines show the deallocation by the oping client, lines 4-6 the deallocation of the client side flow endpoint by the IPCP. Line 7 shows the client process (5929) has exited. The flow will time out at the server side, and then the logs in the IRMd show the deallocation initiated by the oping server (lines 8-10) and finished up by the ipcp (lines 11-14).

	This concludes this first short tutorial. All running processes can be terminated by issuing a Ctrl-C command in their respective terminals or you can continue with the next tutorial.		This concludes this first short tutorial. All running processes can be terminated by issuing a Ctrl-C command in their respective terminals or you can continue with the next tutorial.