Member Avatar for jkon

Hello , first of all I need to make clear that although I understand , and have done projects modifying code that is already there (and created my own minions) , in the core of C and C++ I wouldn't consider to know those a bit, I have just a glimpse of what those languages are capable of. Let's suppose that you have a program that runs endless (almost) in C++ (lets call it A) and it can take take something for input and throw out a result. Differentiating input / outputs could be done through a port of this and I guess that would be a better way because input would come only from inside the server (from program B). Then you have one second program that is run through CGI it would take the server data from an HttpRequest would pass it to A , take the response from A and serve it to the caller.

I am in the process of thinking to trying to archive such an architecture. I know the relationship C and C++ has with every major web company and any (in my knowledge , I know for Java and PHP) OOP like language. But what I am asking is quite different, it is an another architecture. Should I give it a try it , or there are some other things that I am missing?

Edited by jkon
  • 2 Contributors
  • 2 Replies
  • 292 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by jkon

Dani AI

Generated

The pattern describes — a long‑running C++ worker ("A") that does the heavy work and a short adapter that translates HTTP into requests for A — is perfectly viable. The main missing detail in the original post (and what ’s prompt hints at) is what the architecture is trying to optimize: latency, throughput, memory footprint, developer speed, or safety. Classic CGI (fork/exec per request) kills latency and throughput; replace it with a persistent adapter (FastCGI/SCGI, a small HTTP front end, or embedding an HTTP listener in A) so requests don’t spawn a new process each time.

Choose an IPC that matches the constraints. Unix domain sockets are fast and local-only; loopback TCP is portable and simple to debug; shared memory/message queues give the best raw throughput but add complexity (synchronization, lifecycle). Always design a clear message framing protocol (length prefix or delimiter), pick a serialization (JSON for simplicity, compact binary/protobuf for speed), and defend every parser — C/C++ makes it easy to introduce unsafe reads and buffer overflows.

For minimal resource use: a persistent worker reduces CPU spent on process churn but holds memory longer. Use a bounded worker pool, reuse buffers, avoid per-request heap churn, enforce request timeouts and queue limits, and apply backpressure when the system is saturated. For high concurrency prefer event-driven I/O (epoll/kqueue) or a small thread pool rather than one process-per-request.

Operational and safety notes: run A under a supervisor (systemd/supervisord), use privilege separation and chroot where appropriate, instrument with metrics and health checks, and add graceful shutdown. During development use sanitizers (ASan/UBSan), fuzz parsers, and load-test the whole pipeline to validate the “minimum resources” claim — real savings depend on workload shape and implementation details. Quick checklist:

  • avoid classic CGI, use a persistent adapter
  • prefer Unix socket or loopback TCP with explicit framing
  • reuse buffers and bound concurrency
  • enforce timeouts, supervise and log
  • harden parsers and drop privileges

Recommended Answers

All 2 Replies

Member Avatar for rubberman

What exactly do YOU mean by "archive" an architecture? What precisely are you trying to accomplish?

Member Avatar for jkon

That was a spelling mistake I made. With “archive” I meant achieve . And of course “achieve an architecture” isn't accurate , but better would be “implement an architecture”.

There are two questions here , the first one if that architecture is something that can be done , I thought asking here before trying it because someone might have experiences to share about it , or even opinions of how to implement it.

The second question (that the actual implementation will show in facts) is if such an architecture would result a web application that uses “the minimum” of server resources.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.