CODEWITHSUNDEEP
pythonoopasynchronousconcurrencyparallel-processing
Kuba Chrabański
Kuba Chrabański

Reputation: 655

Most suitable node-server communication design

I struggle with designing a part of my project. The idea is that N nodes (each with one camera) would be continuously sending frames to a server for object detection and then the server would resend a response to each node with some information.

The goal is to handle each node possibly independently and to be able to receive next frame and process previous at the same time.

As in Python, threads running in parallel are not in option, I'm considering a few approaches (assuming that I have a CPU that is capable of handling N * 2 threads in parallel:

1) The server would spawn two processes (communicating with each other) for each node (one for receiving frames, and one for object detection). (those processes would run independently from the main process)

2) The server would be single-threaded and asynchronous. Every received frame would be submitted to a process-pool for detection.

3) The server would spawn a thread for each node (one thread would handle receiving frames from one node). Every received frame would be submitted to a process-pool for object detection.

4) The server would spawn a thread for each node and two separate threads within this thread, one for receiving and one for object detection

Which approach seems to have the most sense? Would you suggest something different?

Upvotes: 0

Views: 33

Answers (1)

BetaDev
BetaDev

Reputation: 4684

I love architectural kind of problems, Here what I would do if I have to do this project.:
Workflow:

  1. Node will send request to the server including frames and node ID
  2. Based on the node ID and the frames, Server will create a job in a queue using redis in memory storage to keep track of the jobs sent by the nodes and also store each request into a DB
  3. Server will process each jobs by running a worker on the server which will fetch and process each jobs from redis queues.
  4. Update Job Record : Once done, the job will be marked as completed and result will be saved.
  5. Node can make a call to the server to get status of each job posted by the node.

You need to create REST API interface on the server to post the job from the node and save that request to the DB and create a job based on that request and also push it to the redis queue. A worker will automatically pull out the jobs from the redis queues and update the DB record based on the processing result.

You need following on the server side:
- REST API
- Redis queue (RQ) Link
- DB server

Using this architecture you can easily return light-weighted result immediately to the client and keep all the jobs under processing. RESTful Architecture is widely used architecture but for time consuming jobs, we use queue processors and client will make request to us to check the status of any jobs posted to the server. If you need I can draw the architecture including much more detail.

In short: if you have client server architecture use REST APIs to communicate and post each request in an in-memory queue storage if the request posted by client is time consuming process and have multi-step jobs to do. And using this architecture you can post any numbers of jobs as well as multiple workers, load balancers for the performance.

Upvotes: 1

Related Questions