stream module programming problem...

stream module programming problem...

Post by Tim Carma » Sun, 02 Mar 2003 19:46:17



stream module programming problem...

How does a stream module know a reply message is destined
to him? For example, there is a stream constructed as following:

[stream head]--[module A]--[module B]--[driver]

If both module A and module B send a DL_INFO_REQ
message to driver and that driver replys two
DL_INFO_ACK,then when module B find this upstream
message, how can he know is it a reply to him
or to module A? If he thinks this reply message
is destined to him, he shall free this message,
else he shall passthru it. So, how to tell?
thx.

 
 
 

stream module programming problem...

Post by Vassilii Khachatur » Thu, 06 Mar 2003 08:22:23


Quote:> [stream head]--[module A]--[module B]--[driver]

> If both module A and module B send a DL_INFO_REQ
> message to driver and that driver replys two
> DL_INFO_ACK,then when module B find this upstream
> message, how can he know is it a reply to him
> or to module A? If he thinks this reply message
> is destined to him, he shall free this message,
> else he shall passthru it. So, how to tell?
> thx.

One way would be for B to count the DL_INFO_REQs
it passes downstream (including its own),
subtract the # of DL_INFO_ACKs received from downstream,
and only treat the message as destined for itself if
the counter is 0 (because the driver below would process
them in a FIFO order). This is the most general way
of what I could think of, but it requires some processing
overhead on your part - make sure you tune your code.
This approach is the closest to the letter of the question.

Another way (if you know the upstream will send the
DL_INFO_REQ) would be to wait until it does it, and then
peek into the response message for the data you want to
learn before you pass it upstream. This depends on
the upstream behaviour habits.

You might combine the 2 approaches by spying on the results
for the upstream's request and flagging you don't need it
any more (if that's the case). If you haven't got the
upstream sending it till when you need it yourself,
then request it yourself, again flag that you've got the info
so that the spying/counting code will fall through on
the flag and just fwd the traffic up/downstream when
it's not yours.

Last thing would be always to fwd it upstream and hope
they'll be discarded eventually. Depends on the app
above the stream head, though. Dirty trick, but easiest
to do in a prototype, probably.

 
 
 

1. stream module programming problem...

stream module programming problem...

How does a stream module know a reply message is destined
to him? For example, there is a stream constructed as following:

[stream head]--[module A]--[module B]--[driver]

If both module A and module B send a DL_INFO_REQ
message to driver and that driver replys two
DL_INFO_ACK,then when module B find this upstream
message, how can he know is it a reply to him
or to module A? If he thinks this reply message
is destined to him, he shall free this message,
else he shall passthru it. So, how to tell?
thx.

2. UUCP, unable to get linux system to answer the modem

3. SysV.4 Streams and Modules programming problem: 2

4. Linux Frequently Asked Questions with Answers (Part 6 of 6)

5. SysV.4 Streams and Modules programming problem: 1

6. mod_ssl and Apache

7. Linux (PCI) crashes my bios setup

8. What happens if a stream module is pushed onto multiple stream driver?

9. Solaris x86 failure to push streams module into network stream

10. How to push STREAMS module into socket stream

11. STREAM module read+write queue problem

12. STREAMS MODULE PROBLEMS