Receive String

If Send String is how your local ComfyUI talks to the cloud box, Receive String is how the cloud box talks back - or, flipped around, how the remote machine hands you text it produced. It's the receiving half of the pack's simplest transport, and for all that it sounds boring, it's the node that makes prompt-pushing workflows feel like a two-way conversation instead of a fire-and-forget job.

How it works

Receive String sits on the socket and waits for a message that a Send String node on the other machine pushed at it. It reads the size prefix, streams the payload in 4KB chunks while the progress bar fills, base64-decodes, and verifies the SHA-256 hash the sender embedded - if the bytes got corrupted in transit you get Hash don't match. instead of a garbage prompt. Then it checks the format tag and, assuming the sender really did send a string, decodes it and hands you the text.

The addr and mode inputs are the pack's standard pair: addr defaults to 127.0.0.1:8282, and mode is Client (dial) or Server (listen). Whatever role the matching Send String on the other end has, yours is the opposite - per the README, Client on your local machine, Server on the remote, connected through an SSH tunnel.

What you get out of it

Two outputs:

• string - the received text. This is the useful one. Wire it into a CLIPTextEncode text input on the remote side, or anywhere else a string is accepted locally: a filename, an API result, a status message from the other machine.
• order - the chain counter, pass it to the next Jumper node or anchor it in a PreviewAny.

The order input is how you sequence things. One Jumper chain per workflow, identical on both sides: wire each node's order output into the next node's order input (start with a Primitive Int at 0), and make sure a Receive String's order position matches where its counterpart Send String sits in the other machine's chain. In the pack's example, the remote's two Receive String nodes sit at order positions matching the local machine's two Send String nodes, each one feeding a CLIPTextEncode. That pairing is the whole trick - get the chains out of order and you'll either see Receive unexpected data. or prompts landing in the wrong node.

It's worth knowing that Receive String only accepts strings. If a Send Images gets pointed at it, it raises Receive unexpected data. and you'll wonder why nothing shows up. The format tag in every payload is checked precisely so this fails loudly rather than silently.

Installing it

No dependencies, no model downloads - ComfyUI-Jumper's requirements.txt is empty and the pack only uses what ComfyUI already ships. Install via ComfyUI Manager (search ComfyUI-Jumper) or:

cd ComfyUI/custom_nodes/
git clone https://github.com/myonmu0/ComfyUI-Jumper

Then restart ComfyUI.

Where people get burned

The pack-wide known issue applies here: cancel doesn't work while a Jumper node is running, so restart ComfyUI if you need to abort. And because this is unencrypted TCP with no authentication, the README is firm that remote use requires an SSH tunnel - the ComfyUI ecosystem's own security history (unauthenticated exposed instances get abused, fast) is exactly the reason that advice exists. Keep the tunnel up, keep the chains in order, and Receive String just works.