Multiple MSP connections

[Artur Sterz]

Hi,

is it possible for a MSP server to handle multiple connections on the same port? I am using the CLI commands msp connect and msp listen. If a client is already connected to the server on a port, I have to open a new port. This is somewhat confusing and not like (e.g) TCP works. I thought you differentiate the connections the same way TCP/IP does with the 4-tuple (src_ip, srp_port, dst_ip, dst_port).

Or maybe I am just using it wrong?

And the forwarding option forwards on an MSP port to a TCP/IP port, right (on server side)?

[Jeremy Lakeman]

A pair of;
`msp connect --forward...`
`msp listen --forward...`

Essentially acts as a tcp proxy. All incoming connections made to the connect end, will pop out of the listen end.

But without either --forward argument, we have no choice but to implicitly set --once. There's not much we can do with multiple streams at the same time with just the one stdin / stdout pair.

So yes a server can accept multiple connections from different clients, or even the same client, so long as the client address / port is unique.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
To post to this group, send email to serval-project-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Lakeman]

As a side-note, I have contemplated adding an `msp listen --fork "<cmd>"` variant that would create a pair of pipes, fork redirect stdin & stdout then exec the command.

Similar in concept to inetd.

On Tue, Sep 19, 2017 at 11:05 PM, Jeremy Lakeman <jer...@servalproject.org> wrote:

A pair of;
`msp connect --forward...`
`msp listen --forward...`

Essentially acts as a tcp proxy. All incoming connections made to the connect end, will pop out of the listen end.

But without either --forward argument, we have no choice but to implicitly set --once. There's not much we can do with multiple streams at the same time with just the one stdin / stdout pair.

So yes a server can accept multiple connections from different clients, or even the same client, so long as the client address / port is unique.

On Tue, Sep 19, 2017 at 10:16 PM, Artur Sterz <goo...@artursterz.de> wrote:

Hi,

is it possible for a MSP server to handle multiple connections on the same port? I am using the CLI commands msp connect and msp listen. If a client is already connected to the server on a port, I have to open a new port. This is somewhat confusing and not like (e.g) TCP works. I thought you differentiate the connections the same way TCP/IP does with the 4-tuple (src_ip, srp_port, dst_ip, dst_port).

Or maybe I am just using it wrong?

And the forwarding option forwards on an MSP port to a TCP/IP port, right (on server side)?

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubsc...@googlegroups.com.

[Artur Sterz]

Sorry, but I don't get it. I try to be more precise:

I have a server listening on MSP-port (say) 10. On this port, an application is running. Now, I have n clients with unique SIDs each. What I now want is to be able to connect m <= n clients to that server on MSP-port 10. Furthermore, I do not want any TCP/IP forwarding. Just plain Serval (of course, there is IP routing under the hood and Serval uses by default UDP, but I do not want to care about underlying technologies. Just Serval). The listening application could and can do the demultiplexing.

I start the server with servald msp listen 10

The clients are connected with servald msp connect <server SID> 10.

But, as soon the first client is connected, all other clients just fail without an error message. In the logfiles, I see the following:

DEBUG:[  165] 16:35:19.917 msp_proxy.c:662:app_msp_connection()  {msp} - Connecting to A3FCCA35FBEA36F2EDE964F7B6A6BC9C4B3A6479F8986C4768C11CAD5BF7FB48:1

DEBUG:[  165] 16:35:19.928 msp_common.h:177:msp_write_ack_header()  {msp} Sending packet flags 04 (acked ffffffff)

DEBUG:[  165] 16:35:19.928 msp_client.c:576:process_packet()  {msp} Bound to 8DF5B494BEE572DA5461C08EE4FDC1FAED512AC1447F5185C1C72DE4E7056E2B:262

DEBUG:[  165] 16:35:19.938 msp_common.h:304:msp_process_packet()  {msp} Closing socket due to STOP packet

DEBUG:[  165] 16:35:19.938 msp_proxy.c:277:msp_handler()  {msp}  - Connection with A3FCCA35FBEA36F2EDE964F7B6A6BC9C4B3A6479F8986C4768C11CAD5BF7FB48:1 closed suddenly

DEBUG:[  165] 16:35:19.938 msp_client.c:528:msp_release()  {msp} Releasing mdp port binding 262

The other client, which is connected to the server uses MSP-port 261, as I can see in the corresponding log file.

Is this intended behavior?

Am Dienstag, 19. September 2017 15:40:47 UTC+2 schrieb Jeremy Lakeman:

As a side-note, I have contemplated adding an `msp listen --fork "<cmd>"` variant that would create a pair of pipes, fork redirect stdin & stdout then exec the command. 

Similar in concept to inetd.

On Tue, Sep 19, 2017 at 11:05 PM, Jeremy Lakeman <jer...@servalproject.org> wrote:

A pair of;
`msp connect --forward...`
`msp listen --forward...`

Essentially acts as a tcp proxy. All incoming connections made to the connect end, will pop out of the listen end.

But without either --forward argument, we have no choice but to implicitly set --once. There's not much we can do with multiple streams at the same time with just the one stdin / stdout pair.

So yes a server can accept multiple connections from different clients, or even the same client, so long as the client address / port is unique.

On Tue, Sep 19, 2017 at 10:16 PM, Artur Sterz <goo...@artursterz.de> wrote:

Hi,

is it possible for a MSP server to handle multiple connections on the same port? I am using the CLI commands msp connect and msp listen. If a client is already connected to the server on a port, I have to open a new port. This is somewhat confusing and not like (e.g) TCP works. I thought you differentiate the connections the same way TCP/IP does with the 4-tuple (src_ip, srp_port, dst_ip, dst_port).

Or maybe I am just using it wrong?

And the forwarding option forwards on an MSP port to a TCP/IP port, right (on server side)?

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
To post to this group, send email to serval-proje...@googlegroups.com.

[Jeremy Lakeman]

Right, so you are using the msp commands implemented in msp_proxy.c, which were modeled based on the functionality of netcat.

$ servald msp listen [port]

Is functionally equivalent to;

$ netcat --listen [port]

In that msp listen accepts a single msp connection, then pipes data from stdin to the msp connection, and from the msp connection to stdout.

Using small memory buffers and poll() to handle shuffling bytes around using a single thread. But rejecting any further connections.

If you want to support multiple clients with a single server, you will either have to implement your own msp server application.

So the byte sent / received over each msp stream are handled entirely by your program.

See https://github.com/servalproject/serval-dna/blob/development/doc/Mesh-Stream-Protocol.md for more information.

Or write a small extension to the existing msp proxy implementation that is equivalent to;

$ netcat --listen [port] --exec 'cmd' --keep-open

So when each new connection is accepted, instead of initiating an outgoing tcp connection, as with the --forward argument. A pair of in memory pipes are created, and redirected to the stdin and stdout of a new child process.

And by small, I really do mean small. All the existing pieces of code in msp_proxy.c that shuffle bytes around and maintain connection state would be reused. The only changes required would be in parsing arguments, and here;

https://github.com/servalproject/serval-dna/blob/development/msp_proxy.c#L321

Where instead of initiating a new tcp connection, the child process would be created. Similar to;

https://github.com/servalproject/serval-dna/blob/development/dna_helper.c#L192

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubsc...@googlegroups.com.

To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at https://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.

To post to this group, send email to serval-project-developers@googlegroups.com.

[Artur Sterz]

Oh, ok. Now I understand, thank you. Unfortunately, this is not what I try to do :D

I already built a program, which more or less did what you suggested. But I also needed MDP and Rhizome. Und within about 6 months you changed really a lot. Therefore, I started to reimplement everything in Python using only your REST API or the CLI if REST is not available. I want be able to survive your internal changes :D

Don't get me wrong, it is really great that Serval is under active development. But for me it means I need to think differently.

But okay. Maybe I can get around somehow.

Thank you :)

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.

To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at https://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.