Сетевая библиотека вместе!

Здравствуйте уважаемые обитатели форума,
Я недавно начал делать сетевую библиотеку на C# как под обычные консольные приложения, так и под игровой движок Unity3d. Хотел бы попросить помощи, а именно:

Посмотреть код и по возможности сделать какие-то поправки в нём. Давайте делать сетевой движок своей мечты вместе!
Ссылка на codeplex setnet.codeplex.com

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ребят, может кто-то захочет вместе работать над таким проектом?

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

неужели в винде появились асинхронные сокеты?

а вы о чем то другом подумали?

о классическом бсдешном event-loop-е

select() есть и работает практически так же, хотя AFAIR ограчен 64 сокетами. Но он не интегрируется с обычными десктрипторами (это основное из того, почему я ругался на автора Winsock). На IOCP забахивается обобщённый event loop на все виды объектов. Ограничения — при этом нет свободы миграции между IOCP (в kevent, epoll, аналогах это делается тривиально, а тут — дзуськи, или я не знаю какого-то секретного хака), иногда она полезна (например, самый эффективный http сервер возникает, когда быстрые и медленные соединения разносятся по разным группам исполнителей)

select() работающий на дескрипторах в винде построенной на хендлерах — баловство.

О! Вот Вы своей репликой чётко показали, за что именно я хочу автора Winsock разжаловать в говномёсы.

Это в Unix то, что подаётся в select() это дескрипторы уровня ядра, и они ничем не отличаются от таких же полученных от open(), pipe() и прочих.

В случае Windows — функции — аналоги libc в CRT отдают нечто из собственной таблицы трансляции, а внутри ведут хэндлы. А вот то, что выдаётся по socket() - это уже хэндл уровня соответствующего API, и ничего общего с уровнем CRT не имеет. Если Вы попытаетесь напустить на него, например, close(), получите фигу или вылет нафиг — поэтому в Winsock свой closesocket().
С другой стороны, эти хэндлы не такие же, как файловые — большинство API функций работы с ними отличаются:( И неудивительно — потому что они по сути есть ссылки на структуры, внутри которых ядерный хэндл — только одно из полей. Все API, которые должны работать с ними — «снимают» обёртку в виде этой структуры и дальше общаются с ядром уже через спрятанный внутри хэндл. Ну не бред?

Сокеты-то в ней, как, наверно, в любой реализации сети, асинхронные «внутри»; более того, в отличие от файлов, у сокетов нет проблем переключения между синхронным и асинхронным стилем. Хотя это и дорогой подход (на Kegel’овские 10K сокетов он уже даст дикий оверхед, всякие IOCP будут дешевле).
(Другой вопрос, что автора классического Winsock API надо разжаловать в говномёсы и не пускать больше никогда за клавиатуру — это такие, как он, приводят к тому, что MS ни с чем не совместим, и ещё и гордится этим.)

А чем SignalR не устраивает? www.asp.net/signalr
Ну и WCF поддерживает разные протоколы и транспорты. Если хочется чего-то своего то лучше его расширить, чем велосипед изобретать:
social.technet.microsoft.com/...rt-channel.aspx

Смотрел WCF одно время, он как-то сильно был завязан на SOAP в сообщениях, даже при кастомизация делалась в рамках того, как все привести к виду SOAP

Хочу получить опыт в сокетах. Вот и хочу делать с 0.

Подписаться на комментарии