Re: Istream pipes - COM Discussion Boards

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}

30-Mar-06 18:00

This issue is not releated to COM.

Steve

Istream pipes

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}30-Mar-06 10:52

30-Mar-06 10:52

is there a pre-existing implementation of IStream (or ISequentialStream) that wraps around pipes or sockets or something? I want to send lots of data between two COM objects in different apartments & need something efficient

--Jason

Stephen Hewitt30-Mar-06 11:26

30-Mar-06 11:26

The normal way to solve such a problem is simply to marshal a pointer to the receiving COM object to the senders apartment and then the sender can simply call a method on the receiver (really the receiver’s proxy) and push the data at it - There is no need for pipes and the like.

Steve

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}30-Mar-06 11:41

30-Mar-06 11:41

Sure, that's fine if you have a finite amount of data transfered synchronously from object 1 to object 2.

But what if object 1 is pumping out an infinite (or at least, indefinitely large) stream of data, say in 100 byte chunks, one chunk every 100usec, and I want object 2 to be able to process the stream of data at a slower rate (e.g. 1000 chunks every 100msec, or whenever object 2 gets a chance)?

(think of MP3 or video streaming, though in my case the application is completely different)

--Jason

Stephen Hewitt30-Mar-06 11:47

30-Mar-06 11:47

In that case the receiver could simply queue the data and not process it immediately. The sender could call CoTaskMemAlloc to get some memory and fill it, then call the method on the receiver’s proxy and give it the memory block. The receiver would stash the address of this memory block in a queue. When the receiver gets around to it would process it and free the block by calling CoTaskMemFree.

Steve

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}

jason s {3E44F2FF-8ED8-4ff9-8669-6672A203F776}30-Mar-06 12:07

30-Mar-06 12:07

right, but then I have to take an RPC call every time the sender wants to send something. This is awful expensive. And at a source rate of 1 chunk every 100usec, it essentially won't work unless the two objects live in the same apartment. Some informal experiments seem to indicate inter-apartment calls on my CPU take between 100us and 1msec depending on how much data is marshalled. Actually in a lot of cases my chunk size might be 10 or 20 bytes every 100usec, so there's a tremendous amount of overhead here for the data rate.

I've thought of having the sender batch it up into larger chunks arriving slower & doing essentially what you're talking about, having the receiver queue things explicitly (which is what I'm doing now to get around the problem), but that's a bit kludgy. The major downsides in my application are that [a] my object's clients have to know about & manage the batch-processing (not that bad, but nevertheless a pain) and [b] if the sender dies before it finishes a batch, I lose the chunks that the sender had queued up in the partially-stored batch. This is a datalogging application & I need to lose as little data as possible. (especially if the last bits of data would tell me something about the cause of the sender's death; the sender program may be getting this data from an unreliable program which could cause it to crash. yes I know programs shouldn't crash but sometimes they do, especially if they're not mine Big Grin | :-D

)

If I were to use a pipe (and I'm implementing both objects so they could, theoretically use out-of-band methods to talk to each other, though I'd rather not), the CPU overhead seems like it would go way down (admittedly, haven't tried it yet), and everything that the sender sticks into the pipe before it dies should eventually arrive at the receiver (even if the receiver takes a bit of time to get around to reading from the pipe).

Summary: I care about throughput, not latency, and the # of method calls through standard COM eats into my throughput too much, so I was hoping there would be a pipe for me to stuff bytes into. These are really bytes, they're not interface pointers or BSTR's or anything. (Or if they do mean something, they're handled at my application level.)

--Jason

Stephen Hewitt30-Mar-06 12:25

30-Mar-06 12:25

In the scheme I described earlier using CoTaskMemAlloc you only send the address of the memory block and perhaps its size - Not 20 bytes. That said, if you want to use pipes the only real problem is getting the handles to the pipes to the sender and receiver. You could use CreapeNamesPipe and transmit the name of the pipe.

Steve

Andy Brummer31-Mar-06 11:18

Andy Brummer

31-Mar-06 11:18

If you are interested in getting the highest performance, I would think that a memory mapped file like this would produce the highest performance:

http://www.codeproject.com/threads/XQueue.asp[^]

Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you.
-Chris Maunder

ActiveX Control

Anthony988730-Mar-06 9:04

Anthony9887

30-Mar-06 9:04

Hi,

I'm trying to create a multiple instance of the same ActiveX(OCX)objects from a container application(Dialog). The problem is that the multiple instance of each object share the same process. Is there a way to create the objects per process?

Thanks

Roger Stoltz30-Mar-06 11:17

Roger Stoltz

30-Mar-06 11:17

Anthony9887 wrote:
The problem is that the multiple instance of each object share the same process.

Of course, that's part of the whole idea with an ActiveX control since an ActiveX control is in fact a DLL encapsulating with one or more COM objects with automation interfaces and usually a GUI.

Anthony9887 wrote:
Is there a way to create the objects per process?

Why? It doesn't make sense.
It would be like being forced to start Word to be able to perform a spell check in Outlook.

What are you trying to do and how can the above be a problem?

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Anthony988730-Mar-06 13:31

Anthony9887

30-Mar-06 13:31

Hi Roger,

I have a custom server(OCX) which samples data from a D/A hardware through a container application. I want to be able to have 1 container application, that have many server objects sampling data from multiple hardware. When I create the first instance of the server object, it connects and samples, when I create the instance of the second server object, it connects, but the previous object is no longer sampling. When I call a method from the first server object to start sampling, the second object begins sampling. I'm a little confused? Any ideas?

Regards,

Roger Stoltz30-Mar-06 20:57

Roger Stoltz

30-Mar-06 20:57

I don't know what kind of hardware you're using or how your server is implemented.
However, I suspect the server to some kind of functionality to be able to select which hardware to use where you provide an index or some string to identify the hardware, e.g. "COM1". Otherwise you would not be able to use multiple hardware, which may actually be the fact, in theory, if the server is badly designed.

Regarding the fact that your first instance of the server stops sampling when you create a second server could mean a lot of things. One could be that both servers are using the same hardware because both servers use some kind of default hardware index or similar.

Without more information about your server's interface at least, it's not possible to help you further. Besides from guessing about how it should work...
Code snippets of how you create your server and what hardware you're using would be nice, as well.

--
Roger

It's supposed to be hard, otherwise anybody could do it!