Is there a way to ensure connecting to the same node twice from a public client? I have a websocket and simultaneous api requests that I want to make sure are both handled by the same machine instance in order to access local state.
This sounds like a perfect use case for fly-replay! Using the fly-replay header you can make a “router” app and route subsequent requests to the correct node. I am going to add some stuff to the docs about using fly-replay with websockets later this week.
2 Likes
If you’re not using Fly’s HTTP handlers (ie fly-replay wouldn’t work), then Machine VMs come with a stable public IPv6 (for the time being) that clients can pin to (env var FLY_PUBLIC_IP).
Be wary of zombie machines, however.
Is there a way to send fly-replay from the client to avoid the extra round trip of processing the request at the wrong node and being redirected?
Not right now, no. But fly-replay has low overhead. Our edge handles them really quickly so any extra round trip added is negligible.
Hmm, on a running fly machine I can’t seem to connect to any ports on $FLY_PUBLIC_IP, either an internal_port or the external one, either from the client or within ssh to the machine itself. What am I missing?
1 Like
@orph I’m also reminded that you can use fly-prefer-region and fly-force-instance-id from the client
(Thanks @kurt)
Ahh sweet, this sounds perfect - are there docs for this anyplace?
I can see why services.ports / services.internal_ports aren’t accessible when connecting to FLY_PUBLIC_IP directly…
Though, one must be able to (I haven’t used it in a long time myself, so it may have stopped working) connect to FLY_PUBLIC_IP over experimental.allowed_public_ports (ref, via).
Note, connecting straight to FLY_PUBLIC_IP may bypass (I am not sure) Fly Edge (and its handlers, DDoS protection, etc).