Hi all, Would it be possible to install software (MSI) from within a Windows Service written in c# which is running as LocalSystem? What we're looking for is a concept such as used by anti-vurus applications. Thanks, Peter

Fot those interrested, Heath's hint returns a read-only reference to the registry key. Few bytes changed and it works: public override void Install(IDictionary stateSaver) { this.Description = "Blah blah."; base.Install(stateSaver); string p = @"SYSTEM\CurrentControlSet\Services\" + serviceInstaller1.ServiceName; RegistryKey key = Registry.LocalMachine.OpenSubKey(p,true); { if (key != null) key.SetValue("Description", description); } } Ciao and thanks for your help Heath! Peter

Hi all, Does anybody know how to set a windows service description? The serverinstaller component's Displayname property maps to the Service Name in the Services MMC snap-in. The Description in the MMC is empty. I can't find any property that maps to this description. Thanks, Peter

Well... the performance gain is nothing. I didn't mentio it in my code posted, but inside the While loop there is a blocking call. This is exactly the same code in the single thread and new thread code. So that doesn't make any difference. I believe the CPU would go 100% if no blocking call was inside the loop and Thread.Sleep(0) was missing... Thanks Peter

Hi all, An interresting problem in the context of interprocess communication. Consider following code: public void StartSepThread() { ThreadStart tsThread = new ThreadStart(RunServerSepThread); TestThread = new Thread(tsThread); TestThread.Name = "IPC.Test"; TestThread.Start(); } public void RunServerSepThread() { while(true) { (lot of code here...) } } The code above proves to be 50% less performant than following code: public void RunServerSameThread() { while(true) { (exact same code here...) } } When running the server in the same thread, we are able to move 163 Mbit/sec of data between two running processes. However, when running the same code as a seperate thread, performance goes down by almost 35% to a level of 111 Mbit/sec. Anybody any idea what this might be??? Thanks

MS article for VB but it should be easy. http://support.microsoft.com/kb/811399/EN-US/[^]

The desired producer/consumer config is one-to-one. The scope of this application (which is part of a larger solution) is a single machine. We conceive several Windows Services that make up the machine solution. A first one uses sockets to listen for incoming connections and parses streams into atomic messages according to a protocol specification. A second service should handle decryption, a third inspection, and a fourth will be a router that forwards plain-text messages to several back-end machines. Messages always have a minumum length of 4 bytes length (mapped to an Int32), 4 bytes Transaction Number, 10 bytes of flag fields, and finally the message itself. So theoretically the max length of a message is 4+4+10=18 bytes of headers plus an Int32's MaxValue which would then be 2,147,483,665 bytes. In real life this will not be the case, messages will never exceed 150 bytes, including the header. The typical size will be around 50 bytes. There is also no need to queue messages within the mem mapped file mechanism as it is already covered with our own queueing mechanism which makes use of IO completion port threading in the background. Thanks, Peter

Many thanks for your replay. I know the risks of moving away from serialization (and standards) but I desperately need the speed. The type of solution is a protocol front-end handling over 100K messages per second on a quad Xeon machine. I was surprised when we were testing how far we could go in opening the message payload for inspection reasons: the performance price for a single extra string operation (such as UrlDecode) costs about 3.000 messages per second less throughput... Imagine. I've been looking at Christoph's framework, it's a great thing, but it becomes unstable when moving more than 12 Mbit/s (which is around 10.000 msg/sec). The single-process architecture, as it exists today, behaves predictably and inspects and routes up to 180 Mbit/s of message data between components. Also, we've seen some exceptions when either the producer or the consumer dissapears from the process list under load conditions above 5 Mbit/s. Maybe it's synchro-related or the custom queue implementation, I'm not sure. Anyway, thanks again for thinking along... Peter.

Hi all, I am trying to get on top of interprocess communication. Most -if not all- of the articles around handle IPC either through a mailbox mechanism or memory mapped file wrappers. The latter is probably best and by far the fastest, but I got the feeling everybody is serializing and deserializing objects to do this. In my project I have to exchange (an awful lot of) short messages between processes. There is no need for serialization, the message type and structure is known (style 4 msg length bytes, 4 transaction bytes, message payload etc). The question: would it be possible NOT to do serialization and free the CPU of this burden, but instead write bytes directly to a mem stream in one process and read that same semaphore in another process? Somehow? ;P Thanks in advance, Peter Stevens