какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами
а. оконными
б. без окон
буду признателен за совет.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
DV>какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами
Здравствуйте, Denys V., Вы писали:
DV>какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами DV>а. оконными DV>б. без окон
DV>буду признателен за совет.
Здравствуйте, Denys V., Вы писали:
DV>какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами DV>а. оконными DV>б. без окон
DV>буду признателен за совет.
Здравствуйте, k.o., Вы писали:
KO>они быстрее если мне не изменяет склероз это просто обёртка над shared memory.
для меня пайпы и shared memory абсолютно разные вещи. память — фиксированный объем расшаренной памяти, пайп — это канал без размера для перекачки данных. так что плохо понимаю вашу мысль. пайпы еще бывают с возможностью удаленного доступа, возможно, они отличаются от локальных, но все же интересно в чем разница пайпов и сокетов
Здравствуйте, Denys V., Вы писали:
DV>какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами DV>а. оконными DV>б. без окон
DV>буду признателен за совет.
Сделай кольцевой буфер в разделяемой памяти. Быстрее вряд ли возможно.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, k.o., Вы писали:
KO>>они быстрее если мне не изменяет склероз это просто обёртка над shared memory. U>для меня пайпы и shared memory абсолютно разные вещи. память — фиксированный объем расшаренной памяти, пайп — это канал без размера для перекачки данных. так что плохо понимаю вашу мысль. пайпы еще бывают с возможностью удаленного доступа, возможно, они отличаются от локальных, но все же интересно в чем разница пайпов и сокетов
Поэтому, наверно, и сделали интерфейс в виде пайпов, что просто shared memory не всегда удобно. Вообще, об этом же в документации написано. Пайпы для удалённого доступа, разумеется по другому работают, и тут уже сокеты могут оказаться лучше (см. здесь). Ещё, пайпы поддерживают такие плюшки, как передачу сообщений с гарантированной доставкой и http://msdn.microsoft.com/en-us/library/aa365573(v=vs.85).aspx.
Здравствуйте, uzhas, Вы писали: U>для меня пайпы и shared memory абсолютно разные вещи. память — фиксированный объем расшаренной памяти, пайп — это канал без размера для перекачки данных. так что плохо понимаю вашу мысль. пайпы еще бывают с возможностью удаленного доступа, возможно, они отличаются от локальных, но все же интересно в чем разница пайпов и сокетов
При создании канала явно указывается размер буфера, поэтому данные объемом больше этого буфера передать за один раз нельзя.
Здравствуйте, Denys V., Вы писали:
DV>какой способ IPC лучше всего использовать если нужно гарантированно и максимально быстро доставлять небольшие по размеру сообщения в обе стороны между 2мя процессами DV>а. оконными DV>б. без окон
Оконными или без окон — безразлично.
В системе есть 2 способа создания общей памяти :
разделяемая секция
memory-mapped файлы
В этом случае выделяется одна страница физической памяти двум или большему числу процессов. Поэтому все изменения видны сразу. Для того, чтобы поставить партнера в известность, что изменение произошло (если это вообще необходимо), есть несколько способов : оконнные сообщения, ивенты ...)
memory-mapped файлам можно установить защиту, разделяемой секции — нет.
В системе есть несколько способов передачи копии
пайпы
сокеты
WM_COPYDATA (хотя здесь есть нюансы, так как используется все же mmf)
В этих случаях данные копируются и передаются партнеру. Оригинал остается без изменения.
Здравствуйте, trophim, Вы писали:
T>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>WM_COPYDATA (хотя здесь есть нюансы, так как используется все же mmf)
T>А где можно максимально детально прочесть про детали реализации wm_copydata?
Из книги Рихтера
Well, all this is fine and good if you are sending messages that the system is aware of. But what if you create your own (WM_USER + x) message that you want to send from one process to a window in another? The system will not know that you want it to use memory-mapped files and to update pointers when sending. However, Microsoft has created a special window message, WM_COPYDATA, for exactly this purpose:
When you're ready to send some data to a window in another process, you must first initialize the COPYDATASTRUCT structure. The dwData member is reserved for your own use. You can place any value in it. For example, you might have occasion to send different types or categories of data to the other process. You can use this value to indicate the content of the data you are sending.
The cbData member specifies the number of bytes that you want to transfer to the other process, and the lpData member points to the first byte of the data. The address pointed to by lpData is, of course, in the sender's address space.
When SendMessage sees that you are sending a WM_COPYDATA message, it creates a memory-mapped file cbData bytes in size and copies the data from your address space to the memory-mapped file. It then sends the message to the destination window. When the receiving window procedure processes this message, the lParam parameter points to a COPYDATASTRUCT that exists in the address space of the receiving process. The lpData member of this structure points to the view of the shared memory-mapped file in the receiving process's address space.
You should remember three important things about the WM_COPYDATA message:
Always send this message; never post it. You can't post a WM_COPYDATA message because the system must free the memory-mapped file after the receiving window procedure has processed the message. If you post the message, the system doesn't know when the WM_COPYDATA message is processed, and therefore it can't free the copied block of memory.
It takes some time for the system to make a copy of the data in the other process's address space. This means that you shouldn't have another thread that modifies the contents of the memory block running in the sending application until the call to SendMessage returns.
The WM_COPYDATA message allows a 16-bit application to communicate with a 32-bit application and vice versa. It also allows a 32-bit application to talk to a 64-bit application and vice versa. This is an incredibly easy way to have newer applications talk to older applications. Also note that WM_COPYDATA is fully supported on Windows 2000 and Windows 98. Unfortunately, if you are still writing 16-bit Windows applications, Microsoft Visual C++ 1.52 does not have a definition for the WM_COPYDATA message or the COPYDATASTRUCT structure. You will need to add them manually:
если мне не изменяет склероз это просто обёртка над shared memory.
