# Gather via persistent worker connection from scheduler?
**URL:** https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849
**Category:** Distributed
**Tags:** configuration, worker, distributed, scheduler
**Created:** [June 28, 2024, 7:42pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849 "2024-06-28T19:42:15Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@RaiinmakerWes](https://dask.discourse.group/u/RaiinmakerWes)
#### Post date: [June 28, 2024, 7:42pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/1 "2024-06-28T19:42:16Z")
This is related to [Workers on private network, scheduler on a different network - how to make “gather” step work?](https://dask.discourse.group/t/workers-on-private-network-scheduler-on-a-different-network-how-to-make-gather-step-work/1926), but I’d like to explore a potential solution rather than necro-bumping an old thread.
I have a similar setup with a centralized scheduler running in a cloud provider, and a user-distributed script to run workers at will on arbitrary private computers.I’ve solved for the cloud ingress/egress, so workers are able to successfully connect to the scheduler to self identify and we are able to see the heartbeat calls inside of the scheduler.
When a client connects and submits a job the workers are able to receive and perform the tasks successfully and I see the debug logs in the scheduler indicating the task completion. The problem is again at `gather()`… The scheduler seems to always attempt to initiate a new TCP connect to the worker address, which gets blocked by the private workers’ various and untouchable-for-our-purposes firewalls.
**My question is this - is there any way to persist a TCP or WS connection initiated by the worker, and leverage that communication channel to gather the results?** This is potentially a deal-breaker for us if we can’t solve the gather from the centralized scheduler.
---
### Author:  [@guillaumeeb](https://dask.discourse.group/u/guillaumeeb)
#### Post date: [July 4, 2024, 2:46pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/2 "2024-07-04T14:46:05Z")
Hi @RaiinmakerWes, welcome to Dask Discourse forum!
As mentioned by @crusaderky in the post you mentioned, this does not seem to be how Dask Communications are working. But maybe there is more to it?
---
### Author:  [@RaiinmakerWes](https://dask.discourse.group/u/RaiinmakerWes)
#### Post date: [July 8, 2024, 5:51pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/3 "2024-07-08T17:51:18Z")
Yeah it seems like that sort of persistent connection is an anti-pattern and I stopped effort chasing that down…
I’m now working with ngrok TCP Endpoints to create tcp tunnels. Running into mismatches with the worker `contact-address` provided vs the address used to create the new TCP connection from the scheduler in the gather step. But I may start a new topic for that since it isn’t directly related to this thread.
---
### Author:  [@RaiinmakerWes](https://dask.discourse.group/u/RaiinmakerWes)
#### Post date: [July 9, 2024, 5:19pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/4 "2024-07-09T17:19:09Z")
Got it working 🙂 I wasn’t hooking up contact-address and listen-address properly with the ngrok TCP tunnel.
---
### Author:  [@guillaumeeb](https://dask.discourse.group/u/guillaumeeb)
#### Post date: [July 11, 2024, 3:28pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/5 "2024-07-11T15:28:16Z")
Nice, it would be good if you could share your solution!
---
### Author:  [@RaiinmakerWes](https://dask.discourse.group/u/RaiinmakerWes)
#### Post date: [July 18, 2024, 6:04pm UTC](https://dask.discourse.group/t/gather-via-persistent-worker-connection-from-scheduler/2849/6 "2024-07-18T18:04:15Z")
For sure!
I am working on productizing the final script, then I will absolutely make a follow up post to show a minimally reproducible solution 🙂