Обсуждение статьи тематического каталога: Реализация многопотокового ассинхронного сервра TCP и RPC для ОС Linux (select thread rpc gcc socket)Ссылка на текст статьи: http://www.opennet.me/base/dev/pthread_select_server.txt.html
Хорошо известно, что Oracle Advanced Replication или Informix Enterprise Replication
это либо немедленный ,либо отложенный RPC вызов. Следовательно, среда ОС Linux может порождать проблемы с репликациями баз данных, которые не возникают на платформах , поддерживающих “SUN RPC” , либо “DCE RPC”, так как обе реализации имеют многопотоковую поддержку
протокола RPC.
http://www.linuxjournal.com/article/2204
Remote Procedure Calls
From Issue #42
October 1997
Oct 01, 1997 By Ed Petron
>Linux distributions provide an RPC version derived from the RPC facility developed by the Open Network Computing (ONC) group at Sun Microsystems.кто сказал, что в лине rpc не Sun RPC?
также смотреть тут - $ ls /proc/sys/sunrpc/
и тут - ls /usr/src/linux-source*/Documentation/sysctl/sunrpc.txt
Код, очень старый, багов тьма, да и не для Линухов он изначально написан...Начнем, вот с чего:
"errno!=EAGAIN && errno!=EWOULDBLOCK", да но EAGAIN==EWOULDBLOCK в линуксе, ммм...далее, почти каждая функция под SMP может выдать, останов из-за обслуживания сигнала, т.е. EINTR, иными словами, данный код будет падать в die, или не не падать, но работать не верно...
ЗЫ. Вывод, для высоконагруженных сетевый приложений, Linux - далеко не лучший выбор...
прикольно
>Код, очень старый, багов тьма, да и не для Линухов
>ЗЫ. Вывод, для высоконагруженных сетевый приложений, Linux - далеко не лучший выбор...логика что писец. маркетинг?
Супер-статья! Нижайший поклон автору! =)
Наилучший способ разработки ПО это использование уже готовых оттестированных модулей. К примеру Boost.Asio (http://boost.org) или Unicomm (http://libunicomm.org)
Вторая ссылка в литературе не рабочая.