Mobile Protocol specification - Revision history

Bmng-dev: Formatting, spelling corrections

2014-07-18T10:49:42Z

Formatting, spelling corrections

Thomas: /* setreceivekey */

2014-04-29T09:22:50Z

setreceivekey

Thomas: /* receiving messages */

2014-04-29T09:16:17Z

receiving messages

Thomas: /* The differences in protocol behavior */

2014-04-29T09:09:21Z

The differences in protocol behavior

AyrA: added headers

2014-04-27T22:02:08Z

added headers

Thomas: Created page with "This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication. === intension === if you want to let mobile devices participate ..."

2014-04-27T14:29:48Z

Created page with "This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication. === intension === if you want to let mobile devices participate ..."

New page

This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication.

=== intension ===

if you want to let mobile devices participate in bitmessage communication, you need a gateway device. Theoretically the device could participate like a standard node, but this will cause too much traffic. Even if you have a flat rate, it'll cost to much battery.
This page describes a way, the standard protocol could be enhanced, to let mobile devices participate, at least through a gateway.

=== the gateway ===

The gateway first of all is a standard bitmessage node. As a bitmessage node it connects to other nodes and collects and exchanges objects. The mobile gateway functionality is an extension, an additional protocol variant.

When a mobile device connects to a gateway it will identify itself in the "services" field of the version message to be a mobile device. The gateway will answer in the same field, that it is a gateway.

Therefore the service table has to be enhanced:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This is a normal network node.
|-
| 2 || NODE_MOBILE || This is a mobile device with limited bandwidth.
|-
| 4 || NODE_GATEWAY || This node can send reduced traffic and work as a gateway.
|}

=== The differences in protocol behavior ===

==== sending messages ====

When accessed by a NODE_MOBILE the NODE_GATEWAY will not send any "addr" message, because the NODE_MOBILE will connect to the bitmessage network only through well known gateways. It will neither send a "inv" message, because it wants to reduce the traffic to the NODE_MOBILE.

When accessed to a NODE_GATEWAY the NODE_MOBILE will not send a "addr" message, too. But it might send an "inv" message, when it has objects to share. and it can share already all types of objects with the network.

With this very small protocol changes the NODE_MOBILE is already able to send messages using the bitmessage protocol, but with very reduced traffic load.

==== receiving messages ====

For the receive direction we must bring the NODE_GATEWAY in the position to select the objects the NODE_MOBILE is interested in.
Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must only the objects, NODE_MOBILE is interested in!).

How does NODE_GATEWAY know, which objects are of interest. There are different possibilities to notify this. First of all: every "getpubkey" object is translated into a request. When the object arrives at NODE_GATEWAY or if its already there, it is offered in an "inv" message.

For "msg" and "broadcast" objects it's a little more complicate, because the NODE_GATEWAY has to make the decision. We must add an encrypted method, how the NODE_GATEWAY can get the secret keys of NODE_MOBILE.

@@ Line 5: / Line 5: @@
 This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication.
-=== intension ===
+== Intention ==
-if you want to let mobile devices participate in bitmessage communication, you need a gateway device. Theoretically the device could participate like a standard node, but this will cause too much traffic. Even if you have a flat rate, it'll cost to much battery.
+If you want to let mobile devices participate in bitmessage communication, you need a gateway device. Theoretically the device could participate like a standard node, but this will cause too much traffic. Even if you have a flat rate, it'll cost to much battery.
 This page describes a way, the standard protocol could be enhanced, to let mobile devices participate, at least through a gateway.
-=== the gateway ===
+== The Gateway ==
 The gateway first of all is a standard bitmessage node. As a bitmessage node it connects to other nodes and collects and exchanges objects. The mobile gateway functionality is an extension, an additional protocol variant.
@@ Line 28: / Line 28: @@
 |}
-=== The differences in protocol behavior ===
+== Differences in protocol behavior ==
-==== Network address ====
+=== Network address ===
 Because we have to share private keys between mobile node and gateway, we do ssh encryption on the connection. For that reason the "Network Address" gets an additional (optional) field for the public ssh key.
@@ Line 52: / Line 52: @@
-==== sending messages ====
+=== Sending messages ===
 When accessed by a NODE_MOBILE the NODE_GATEWAY will not send any "addr" message, because the NODE_MOBILE will connect to the bitmessage network only through well known gateways. It will neither send a "inv" message, because it wants to reduce the traffic to the NODE_MOBILE.
@@ Line 60: / Line 60: @@
 With this very small protocol changes the NODE_MOBILE is already able to send messages using the bitmessage protocol, but with very reduced traffic load.
-==== receiving messages ====
+=== Receiving messages ===
 For the receive direction we must bring the NODE_GATEWAY in the position to select the objects the NODE_MOBILE is interested in.
@@ Line 66: / Line 66: @@
 For that we introduce a new Message type:
-==== setreceivekey ====
+=== setreceivekey ===
-receiving this message, the NODE_GATEWAY starts to send "inv" messages and offers the NODE_MOBILE objects. In opposite to a standard node connection, it offers only objects, which are alredy found to be for this node.
+Receiving this message, the NODE_GATEWAY starts to send "inv" messages and offers the NODE_MOBILE objects. In opposite to a standard node connection, it offers only objects, which are already found to be for this node.
 {|class="wikitable"
@@ Line 78: / Line 78: @@
 there might be multiple of this messages.
-NODE_GATEWAY stores this information only as long as the connection exists. It can now filter the objects that are intendet for NODE_MOBILE.
+NODE_GATEWAY stores this information only as long as the connection exists. It can now filter the objects that are intended for NODE_MOBILE.
 Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must be only the objects, NODE_MOBILE is interested in!).
-How does NODE_GATEWAY know, which objects are of interest: It uses the privat key received in "setreceivekey" to filter private messages. Every "getpubkey" object is translated into a request. When the object arrives at NODE_GATEWAY or if its already there, it is offered in an "inv" message.
+How does NODE_GATEWAY know, which objects are of interest: It uses the private key received in "setreceivekey" to filter private messages. Every "getpubkey" object is translated into a request. When the object arrives at NODE_GATEWAY or if its already there, it is offered in an "inv" message.

@@ Line 74: / Line 74: @@
 |-
 | 64||private encryption key||uchar[]||The ECC private key used for encryption (uncompressed format; normally prepended with \x04 )
-Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must only the objects, NODE_MOBILE is interested in!).
+there might be multiple of this messages.
-How does NODE_GATEWAY know, which objects are of interest. There are different possibilities to notify this. First of all: every "getpubkey" object is translated into a request. When the object arrives at NODE_GATEWAY or if its already there, it is offered in an "inv" message.
+NODE_GATEWAY stores this information only as long as the connection exists. It can now filter the objects that are intendet for NODE_MOBILE.
-For "msg" and "broadcast" objects it's a little more complicate, because the NODE_GATEWAY has to make the decision. We must add an encrypted method, how the NODE_GATEWAY can get the secret keys of NODE_MOBILE.
+Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must be only the objects, NODE_MOBILE is interested in!).

← Older revision		Revision as of 09:16, 29 April 2014
Line 63:		Line 63:

	For the receive direction we must bring the NODE_GATEWAY in the position to select the objects the NODE_MOBILE is interested in.		For the receive direction we must bring the NODE_GATEWAY in the position to select the objects the NODE_MOBILE is interested in.
		+
		+	For that we introduce a new Message type:
		+
		+	==== setreceivekey ====
		+
		+	receiving this message, the NODE_GATEWAY starts to send "inv" messages and offers the NODE_MOBILE objects. In opposite to a standard node connection, it offers only objects, which are alredy found to be for this node.
		+
		+	{\|class="wikitable"
		+	! Field Size !! Description !! Data type !! Comments
		+	\|-
		+	\| 64\|\|private encryption key\|\|uchar[]\|\|The ECC private key used for encryption (uncompressed format; normally prepended with \x04 )
		+
	Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must only the objects, NODE_MOBILE is interested in!).		Whenever the NODE_GATEWAY notifies, that NODE_MOBILE might be interested in objects, it sends a "inv" message to offer them (must only the objects, NODE_MOBILE is interested in!).

← Older revision		Revision as of 09:09, 29 April 2014
Line 29:		Line 29:

	=== The differences in protocol behavior ===		=== The differences in protocol behavior ===
		+
		+	==== Network address ====
		+
		+	Because we have to share private keys between mobile node and gateway, we do ssh encryption on the connection. For that reason the "Network Address" gets an additional (optional) field for the public ssh key.
		+
		+	{\|class="wikitable"
		+	! Field Size !! Description !! Data type !! Comments
		+	\|-
		+	\| 4 (or 8)\|\| time \|\| uint32 \|\| the Time. Protocol version 1 clients use 4 byte time while protocol version 2 clients use 8 byte time.
		+	\|-
		+	\| 4 \|\| stream\|\| uint32 \|\| Stream number for this node
		+	\|-
		+	\| 8 \|\| services \|\| uint64_t \|\| same service(s) listed in [[#version\|version]]
		+	\|-
		+	\| 16 \|\| IPv6/4 \|\| char[16] \|\| IPv6 address. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
		+	(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
		+	\|-
		+	\| 2 \|\| port \|\| uint16_t \|\| port number
		+	\|-
		+	\| 1+ \|\| ssh fingerprint \|\| [[#Variable length string\|var_str]] \|\| This field is optional. It contains the ssh fingerprint, for nodes that support ssh
		+	\|}
		+

	==== sending messages ====		==== sending messages ====

← Older revision		Revision as of 22:02, 27 April 2014
Line 1:		Line 1:
		+	{{Template:Stub}}
		+
		+	{{Template:Proposal}}
		+
	This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication.		This is a DRAFT for protocol extensions to enable mobile devices to participate in bitmessage communication.