- Forum
- General C++ Programming
- Network Programming With Shared Data Sto
Network Programming With Shared Data Storage
A short introduction:
A vector of structs shall be provided by a server via network. Clients store its structs in the server's vector and clients search for structs in the server's vector.
The server listens to one socket and reacts in two ways:
If a request to store a struct is received, a thread combined with a mutex protecting the vector handles the request.
If a request to search structs is received, the process with the vector will be copied by using a subprocess via fork.
The distinction was chosen, because threads share the vector and fork operate on a copy of the data.
Is this okay as a design approach?
It would be nice to find somebody (experienced) to discuss this and more detailed aspects.
Greetings Stefan
A vector of structs shall be provided by a server via network. Clients store its structs in the server's vector and clients search for structs in the server's vector.
The server listens to one socket and reacts in two ways:
If a request to store a struct is received, a thread combined with a mutex protecting the vector handles the request.
If a request to search structs is received, the process with the vector will be copied by using a subprocess via fork.
The distinction was chosen, because threads share the vector and fork operate on a copy of the data.
Is this okay as a design approach?
It would be nice to find somebody (experienced) to discuss this and more detailed aspects.
Greetings Stefan
Last edited on
It all depends on what you're trying to achieve.
fork is unix/linux specific. With C++11 better use std::thread:
http://www.cplusplus.com/reference/thread/thread/?kw=thread
Note that creating a thread is costly especially time wise, so that you may not have an advantage.
| If a request to search structs is received, the process with the vector will be copied by using a subprocess via fork. |
http://www.cplusplus.com/reference/thread/thread/?kw=thread
Note that creating a thread is costly especially time wise, so that you may not have an advantage.
My main goal is availability for the clients and the integrity of the data storage. My main idea of design is the following:
I want to separate the storing of the data, named offer, from the searching, named request.
An offer uses TCP and operates on the data directly using mutex. Fork cannot be used, because its child process contains a copy of the parent process data storage.
But threads sharing the same data together with a mutex could be used. The work for the thread is not much and only the core storing in the container has to be controlled by the mutex.
An request uses UDP and operates on a copy of the data structure like snapshot. Here a child process via fork can be used to search on a copy of the data.
The search can be more work depending on the size of the container. To copy the data in a state of integrity a mutex may be needed.
I want to separate the storing of the data, named offer, from the searching, named request.
An offer uses TCP and operates on the data directly using mutex. Fork cannot be used, because its child process contains a copy of the parent process data storage.
But threads sharing the same data together with a mutex could be used. The work for the thread is not much and only the core storing in the container has to be controlled by the mutex.
An request uses UDP and operates on a copy of the data structure like snapshot. Here a child process via fork can be used to search on a copy of the data.
The search can be more work depending on the size of the container. To copy the data in a state of integrity a mutex may be needed.
Topic archived. No new replies allowed.