TCP Nodes

[phoddie]

I've got implementations of the TCP In and TCP Out nodes in place now. They support nearly all of the features except for Status and TLS. Status should be straightforward and will be really nice to use with @ralphwetzel 's MCU plugin for the Node-RED Editor. The TLS client should be straightforward to finish-up once I make a bit more progress on the ECMA-419 TLS TCP socket implementation.

Here's a simple flow I used for testing. It is a terrible HTTP server. It listens on port 8080 for incoming HTTP requests. When the request headers are received, it sends a response of "hello". You can test with curl localhost:8080.

TCP In/TCP Out flow JSON

[
    {
        "id": "055bd4fad5eca191",
        "type": "tab",
        "label": "tcp",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "2e62d5aab3f04b8a",
        "type": "tcp in",
        "z": "055bd4fad5eca191",
        "name": "HTTP IN",
        "server": "server",
        "host": "www.example.com",
        "port": "8080",
        "datamode": "stream",
        "datatype": "utf8",
        "newline": "\\r\\n",
        "topic": "",
        "trim": false,
        "base64": false,
        "tls": "",
        "x": 160,
        "y": 260,
        "wires": [
            [
                "25e1a6813a51c7f9",
                "6f76b76feac7d77a"
            ]
        ]
    },
    {
        "id": "25e1a6813a51c7f9",
        "type": "switch",
        "z": "055bd4fad5eca191",
        "name": "received headers?",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "empty"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 1,
        "x": 390,
        "y": 200,
        "wires": [
            [
                "8c04737cad4926ce"
            ]
        ]
    },
    {
        "id": "975cd27b7a7795c2",
        "type": "tcp out",
        "z": "055bd4fad5eca191",
        "name": "HTTP OUT",
        "host": "www.example.com",
        "port": "80",
        "beserver": "reply",
        "base64": false,
        "end": true,
        "tls": "",
        "x": 790,
        "y": 200,
        "wires": []
    },
    {
        "id": "8c04737cad4926ce",
        "type": "function",
        "z": "055bd4fad5eca191",
        "name": "http response",
        "func": "msg.payload = \"HTTP/1.1 200 OK\\r\\nContent-Length: 6\\r\\nContent-tyoe: text/plain\\r\\n\\r\\nhello!\"\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 600,
        "y": 200,
        "wires": [
            [
                "975cd27b7a7795c2"
            ]
        ]
    },
    {
        "id": "6f76b76feac7d77a",
        "type": "debug",
        "z": "055bd4fad5eca191",
        "name": "debug 10",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "true",
        "targetType": "full",
        "statusVal": "",
        "statusType": "auto",
        "x": 360,
        "y": 340,
        "wires": []
    }
]

The TCP In and TCP Out nodes have the same behavior on the MCU as in Node-RED in my tests. But.... I'm not really sure how developers are using TCP In and TCP Out in their projects. I could use some guidance or help to understand that. Examples would be really great.

I do intend to implement TCP Request as well. It is another chunk of work. And I really have no idea how people are using TCP Request, so I'd be developing against contrived tests. I'd like to get some feedback from developers using the TCP Nodes before taking that on.

FWIW – the Switch Node here uses the "empty" condition which was previously unimplemented but was added as part of the TCP work.

[phoddie]

One detail that the TCP In and TCP Out nodes have to get right for compatibility with projects and integration with the Node-RED Editor is to use the same message format. Here's one request header line output by the flow above running in full Node-RED:

Here's the same line running on an MCU (connected to the Editor through the MCU plug-in):

The only difference is that the MCU uses an IPv4 address instead of IPv6.