|
From: Norman V. <nh...@ca...> - 2001-06-12 06:15:04
|
Alex Perry writes: > >> When I first learnt socket programming I remember having >read that if two >> processes communicate using sockets on the same host the >results could be >> *unpredictable*. > >One of the benefits of working under Windows. Loopback socket >traffic works >on Unix hosts ... and _has to_, because the operating system >relies on it. FYI Currently there is an active thread "Inerprocess communication" on the game developers algoritms list http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Cheers Norman ---- Windows specific advice straight from the horses mouth follows ---- That works pretty well. If you don't want to synchronised by the message pump, then a good alternative is to use shared memory via a file mapping object and create some synch objects (mutexes and events) to control access to it. Another alternative is to use COM to do RPC calls between different components - marshalling the interface across process boundaries. The COM approach would allow you to transparently move to a networked situation using DCOM with virtually no code change if you needed to. Pros and cons of above: WM_COPY Pros: Easy to implement WM_COPY Cons: Always synchronised by the message pump, multithreading trickier. Filemapping Pros: Efficient, can do sophisticated synchronisation Filemapping Cons: Need to handle synchronisation yourself COM/DCOM Pros: Can easily move transparently to DCOM for networked situation if need be COM/DCOM Cons: Need to marshall interfaces, DCOM may be less efficient than custom network solution I'll also repeat the comment I made when this topic came up earlier - that on Windows, a more efficient solution is often to keep everything in the same process in the first place and use multithreading. Depending on the details of your situation, this may or may not be practical. Tony Cox - Lead Engineer Windows Gaming Developer Relations Group http://msdn.microsoft.com/directx |