Passing large binary files in DCOM server client relationship.

[beach9000]

Hi.<br><br>I have a many to one client server DCOM relationship, and would like to exchange rather large amounts of binary data&nbsp;&nbsp;(stored locally in files on either side) between them.&nbsp;&nbsp;Is there an easy way to read the file into memory and send this data to the server in VC++?&nbsp;&nbsp;Or am I going to have to manually parse through the binary files, sending one chunk, and then another?&nbsp;&nbsp;If so, is there a language construct already out there for making this easy?<br><br>Thanks<br><br>

 

[sleonard]

Hi,

I have exactly the same issue and can't find any details to help. If you get anywhere with this query, or if you have already sorted it out, please let me know the solution and I'll do the same.

Thanks,

Stephen ...

 

[LazyMe]

I just using CopyFile is not an option, then I think you're stuck with sending chuncks of data. However, I'm not sure if DCOM would be the best way to do that. It's not designed for that kind of networking. It might be better for performance to use named pipes for that, you'll have to do some testing on that one. Personally I believe that CopyFile would be the easiest and fastest way (I'm not sure how much overhead network copying causes, but it can't be more than DCOM).
Greetings,
Rick

 

[SemperFiDownUnda]

The Biggest problem of sending files or large amounts of data to and from your Business Rules Layer is that with component services you can time out your objects if things get bogged down. Under Component Services Object that run for to long will overrun the package setting for timeouts. This means unless you have sufficient bandwidth that you'll have big problems and even if you do usage spikes can kill your application.

This is why ADO and other similar COM objects AppendChunk(s). This avoids the problem of timeouts. You only send relatively small chunks (optimising the size to suit your need) and this will hopefully mean the transmission time to get your data marshelled doesn't take longer than the timeout of the object.