#2747 [General IO] bi-directional and server/client mode for tcp/udp sockets

[www2]

Hi all.
I have current problem with the FlightGear's generic IO subsystem using tcp/udp sockets.
The problem is that current method for tcp/udp sockets is only one way. (in or out)
This create an problem that a program need be a server and an client at the same time and use two tcp/udp ports.
This is an inconvenient for programmers that create application that interact with flightgear where the serial port have support bi-directional communication (not tested by me).

# the format of the current socket medium
--generic=socket,<direction>,<hz>,<machi**ne>,<port>,<style>,<protocol>

# example for client that only send data to 1.2.3.4 on port 4200
fgfs --generic=socket,out,1,1.2.3.4,4200,tcp,foobar # this setup an 

# example for a server that only lisend for data on port 4201
fgfs --generic=socket,in,1,0.0.0.0,4201,tcp,foobar

My proposal is that we create a medium[1] and i call in this feature request as socketNG.
SocketNG is a new generic IO medium is setup to be easier understand when flightgear act as a host or a client than the current socket medium.
The other things that i think that is an improvement is over the the current socket medium is that socketNG use a URL format for creating a socket connection and add support for ipv6.
(disclaimer: i don't know that ipv6 is support in the current socket medium)

• the format for the socketNG:
  --generic=socketng,<direction>,<hz>,<url>,<mode>,<protocol></protocol></mode></url></hz></direction>

params:

scoketng:       Medium
<direction>:    the direction that the data flows (in,bi,out default:bi)
<hz>:           number of times to process channel per second (floating
                    point values are allow).
<url>:          describe the socket style, ip address, port for the protocol
                    <style>://<ipadress>
                    tcp://123.45.67.89:9000 # create a ipv4 tcp to 123.45.67.89 on port 9000
                    udp://example.org:9001  # create a udp socket that connect the domain example.org on port 9001
                    tcp://[::1]:1234        # create a ipv6 tcp socket for localhost
<mode>:         this select the host/client mode is use for the protocol
                    note: ip adress need be set to 0.0.0.0 for ipv4 or [::] for ipv6 (ipv4 socket is incude with ipv6)
                          Other ip adress are allowed but not recorded.
<protocol>      this is the protocol is use for this connection [1][2]

example:

fgfs --generic=socketng,bi,1,"tcp://127.0.0.1:6900",client,foobar   # ipv4 tcp client
fgfs --generic=socketng,bi,1,"udp://[::1]:4200",client,foobar       # ipv6 udp client
fgfs --generic=socketng,bi,1,"udp://example.eu:4200",client,foobar  # udp client that use dns for getting there ip adress

fgfs --generic=socketng,bi,1,"tcp://[::]:6900",host,foobar      # ipv6 tcp host
fgfs --generic=socketng,bi,1,"tcp://0.0.0.0:6900",host,foobar       # ipv4 udp host

As you see is that the socketNG format is easier to understand when flightgear act as an host or a client than the current socket and plus point is that new protocol's are be easier to write for flightgear. (no need for hacks that app's are host and clients at the same time)
And this open the door for new transport protocol's and support for ssl/tls certification in the future
But i see there is also an need for backwards compatibility to the old socket medium.
The example here under hows how the old socket medium translate to the new socket medium.

example:

fgfs --generic=socket,out,1,127.0.0.1,4200,tcp,foobar 
fgfs --generic=socketng,out,1,tcp://127.0.0.1:4200,client,foobar

fgfs --generic=socket,in,1,0.0.0.0,4200,udp,foobar
fgfs --generic=socketng,in,1,udp://0.0.0.0:4201",host,foobar

As you see in this example that shows how the old socket medium trans late to new scoketNG medium.
This will be internal translate if the user use the old socket medium

In conclusion my proposal for socketNG medium is an improvement the the current socket medium that is better under stand when flightgear act as a host or a client by any user and developer and special for be-directional communication that is current mission in flightgear.
This open also the door for more complex protocols that can be use for communication between flightgear and 3th party apps.
And be-directional communication become inserting if we get support for state machines and execute nasal code in the protocol descriptor files.

[1] $FG_ROOT/Docs/README.IO
[2] $FG_ROOT/Docs/README.protocol