467,892 Members | 1,850 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,892 developers. It's quick & easy.

how to form queues for data storage and how to Handle the matching of the Responses


Dear friends,

I am working on the problem which deals with the data management
of requests and how should we match the responses for the requests to
compare the correct Response.
my problem is like this, say I am intermediary node between "m"
and "n" nodes . n nodes send any of the "p"type of requests to any one
of the "m" nodes on the other side. I have to forward the requests to
one of the node in "m" nodes. The uniqueness of the request is that it
has specific unique resquest filed say "type of service"

I am thinking of maintaining " p" no .of queues for "n" nodes
seperately to send the request and store the requests information in my
intermediary device so that I can compare the responses easily i.e. I
will have to maintain the n*P queues but I want some simple
implementation for this problem. can any one help me out.
my another problem is that if I am maintaining a linked list data
structure for "P" types of requests for each of "n" nodes while I
forward the request I am facing a problem at the data storage of the
request. since after geeting the request from one side of the "n"
nodes. I am forming the structure as local variable to send the request
and storing it in the linked list but I doubt I will loose the data in
the linked list after existing from the function even though I store
the address of in the linked list. how to overcome the problem.

please can anyone specify me where I can get good inforamtion on
this kind of data storage and data matching in "C" implementation using
linux as platform and thread programming.

please help in this regard to solve the problem.

Thanking you all in advance,

Sulaiman

Nov 15 '05 #1
  • viewed: 1156
Share:
1 Reply

"saleem" <su**************@gmail.com> wrote
my problem is like this, say I am intermediary node between "m"
and "n" nodes . n nodes send any of the "p"type of requests to any one
of the "m" nodes on the other side. I have to forward the requests to
one of the node in "m" nodes. The uniqueness of the request is that it
has specific unique resquest filed say "type of service"

I am thinking of maintaining " p" no .of queues for "n" nodes
seperately to send the request and store the requests information in my
intermediary device so that I can compare the responses easily i.e. I
will have to maintain the n*P queues but I want some simple
implementation for this problem. can any one help me out.
Have a queue for each of the "m" nodes, and keep all the information in your
structure.
If there are p types of messages, the natural structure would be a union,
with a single "type" member so you know what the type of a message is.
my another problem is that if I am maintaining a linked list data
structure for "P" types of requests for each of "n" nodes while I
forward the request I am facing a problem at the data storage of the
request. since after geeting the request from one side of the "n"
nodes. I am forming the structure as local variable to send the request
and storing it in the linked list but I doubt I will loose the data in
the linked list after existing from the function even though I store
the address of in the linked list. how to overcome the problem.

LInked lists are good for queues. if you free the data, you cannot then use
it, so use a temporary and call memcpy() to copy the contents to the
temporary. Then delete the node, pass the data in the temporary to your "m"
structures, and if necessary copy again into some permanent structure in the
"m" nodes.

Don't worry about the inefficiency, almost certainly it won't matter.
Programming clarity is what counts.
Nov 15 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Anand Pillai | last post: by
8 posts views Thread by Scott J. McCaughrin | last post: by
16 posts views Thread by David Lauberts | last post: by
12 posts views Thread by Chris Springer | last post: by
1 post views Thread by lupo666 | last post: by
reply views Thread by MrMoon | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.