Сетевое межпроцессное взаимодействие.

просто возьми корбу

Например, можно заюзать: ZeroMQ или Zeroc ICE, или другие подобные системы. А сервер пиши на кроссплатформенном чем-то, будь то Python или какой-нибудь плюсный фреймворк типа Qt Core, или совсем иное. Намекаю, что да - сервер может и должен быть кроссплаформенным.

Виды межпроцесного взаимодействия: Файл, Сигнал, Сокет, Канал, Именованный канал, Неименованный канал, Семафор, Обмен сообщениями, mmap, Message queue, Почтовый ящик.

Подозреваю что мне подойдут или именованные каналы или сокеты. Каналы, насколько я знаю для «Линукс» - «Линукс» не подходят. Тогда нужно писать отдельно для линукс сокет сервер, для винды - именованые каналы. Или же писать - сокеты для того и того в одной библиотеке. Будет ли быстрее и так далее? Может есть и другие варианты.

Клиент планирую писать на java, сервер на с++.

Какие каналы анналы сокеты шмокеты? Ты усложняешь, сам себя запутываешь... Вот бери: ZeroMQ, Zeroc ICE, Apache Thrift, Google Protobufer, и намызывай это певерх TCP.

Ну каг-бы ZeroMQ - это и есть абстракция при работе с сокетами-шмокетами .. :)

Я думал ты про UNIX sockets (UDS), они только для POSIX вроде как, я не разбираюсь в них.

Можно ли написать одну кросплатформенную серверную библиотеку

можно и нужно

Какое сетевое взаимодействие лучше применять

TCP сокеты

TCP сокеты

Так именованые каналы в Винде быстрее чем сокеты нет ? :)

RESTful

Так именованые каналы в Винде

а они, по-твоему, через что работают?

а они, по-твоему, через что работают?

Магия управляет самолётом

через что?

просто возьми корбу

ASN.1 же

Сетевое межпроцессное == сетевое. Как ты собрался по сети через сигналы, семафоры или файл общаться?

жуткое говно из каменного века

Можно через файл в сетевой шаре общаться. Но это далеко не лучший вариант

Приведи пруф, что сетевые именованые каналы работают через сокеты...

а что взамен? грёбаный джейсон?

Сомневаюсь, что есть что то лучше

Сомневаюсь, что есть что то лучше

тебя забылы спросить. rpc свой сначала навелосипедь, что об этом рассуждать.

Виды межпроцесного взаимодействия: Файл, Сигнал, Сокет, Канал, Именованный канал, Неименованный канал, Семафор, Обмен сообщениями, mmap, Message queue, Почтовый ящик.

Это в пределах локалхоста. Скорее всего, тебе нужно что-то поверх HTTP.

Поперхнулся. RPC поверх HTTP? Зачем? О_о

Затем, что HTTP есть везде и проходит через прокси без лишних движений. И RPC over HTTP давно существует (начиналось, кажется, с SOAP, но можно и что-нибудь более JSON-образное найти).

В ОП-посте нет ничего про RPC. Может, топикстартер хочет банальный CRUD.

И про прокси ничего в его посте тоже нет.

Обязательно и непременно последую совету, слившегося анонимуса, не способного аргументировать свои бестолковые точки зрения :).

P.s. так будет пруф, что именованые каналы, если дело касается сети, работают через сокеты?

Именованные каналы работают по сети только под оффтопиком, насколько я помню - это раз.

У них довольно ограниченная область применения - это два. Если я не ошибаюсь опять же, то их можно использовать только в пределах одной подсети, т.к. работают в обход IP-стека.

Короче, это такое ненужно очередное.

Под офтопиком - что это значит?

Под Виндой.

Ну так я знаю, что они работают только под виндой.

wcf (и rest поверх него) на моно :)

Можно ли написать одну кросплатформенную серверную библиотеку или нужно писать две разные серверные программы.

монопенисуально

Что быстрее? Плюсы, минусы, нюансы?

плюсы быстрее

кросплатформенную серверную библиотеку

Если ты о Java, то даже и не думай.

Сокеты.

upd: ИМХО.

У них довольно ограниченная область применения - это два. Если я не ошибаюсь опять же, то их можно использовать только в пределах одной подсети, т.к. работают в обход IP-стека.

- зато быстрей сокетов? Подтвердите. Все остальное - меня устраивает.

У тебя в первом посте написано, что кроссплатформенность требуется.

Меньше гибкости в таком решении.

Не знаю, насколько различается производительность, но вот что пишут на сайте MS в контексте настройки SQL-сервера:

В скоростных локальных сетях производительность сокетов протокола (TCP/IP) и клиентов именованных каналов является сопоставимой. Однако в более медленных сетях, таких как глобальные сети или сети с подключением по телефонной линии, разница в производительности между сокетами TCP/IP и клиентами именованных каналов становится заметной. Это происходит из-за того, что механизмы межпроцессного взаимодействия (IPC) связываются между равноправными узлами различными способами.

В случае именованных каналов сетевые соединения обычно более интерактивны. Равноправный узел не посылает данные до тех пор, пока другой узел не запросит его при помощи команды чтения. Команда чтения перед началом считывания данных обычно запускает последовательность сообщений просмотра именованных каналов. Этот процесс может отнимать много ресурсов в медленных сетях и приводить к избыточному сетевому трафику, что в свою очередь повлияет на работу других сетевых клиентов.

Также важно выяснить, идет речь о локальных каналах или о сетевых каналах. Если приложение сервера запущено на локальном компьютере, где работает экземпляр SQL Server, можно использовать протокол локальных именованных каналов. Локальные именованные каналы работают в режиме ядра и обладают очень высокой скоростью.

Для сокетов TCP/IP передача данных осуществляется более просто и сопряжена с меньшими затратами. Передача данных также использует преимущества механизмов улучшения производительности сокетов TCP/IP, такие как многооконность, отложенные подтверждения и так далее. Это может быть весьма полезно в медленных сетях. В зависимости от типа приложений, достигнутое увеличение производительности может оказаться значительным.

Сокеты TCP/IP также поддерживают очередь незавершенных заданий. Это позволяет обеспечивать ограниченный сглаживающий эффект по сравнению с именованными каналами, которые могут вызвать ошибки занятости каналов во время попытки подключения к SQL Server.

Использование протокола TCP/IP предпочтительно в медленных локальных сетях, глобальных сетях и в сетях с подключением по телефонной сети, а именованные каналы предоставляют более широкие функциональные возможности, повышенную простоту использования и большее число параметров конфигурации, когда скорость сети не является критичным параметром.

https://technet.microsoft.com/ru-ru/library/ms187892(v=sql.105).aspx

Лично я бы не стал именованные каналы для сетевого взаимодействия использовать. В придачу посмотрел бы готовые протоколы и решения - в зависимости от того, какая конкретно задача стоит.

У них довольно ограниченная область применения - это два. Если я не ошибаюсь опять же, то их можно использовать только в пределах одной подсети, т.к. работают в обход IP-стека.

Что? Всё это работает поверх самбы.

UDP ещё быстрее, но не дает гарантий о том что данные вообще придут, хотя для всякого вещания (аудио/видео) это не критично. Я за сокеты.

Значит, ошибся.

Хотя лично для меня это еще один повод смотреть в сторону сокетов.

Ну сокеты так сокеты :)