Здравствуйте уважаемые обитатели форума,
Я недавно начал делать сетевую библиотеку на C# как под обычные консольные приложения, так и под игровой движок Unity3d. Хотел бы попросить помощи, а именно:
Посмотреть код и по возможности сделать какие-то поправки в нём. Давайте делать сетевой движок своей мечты вместе!
Ссылка на codeplex setnet.codeplex.com
Ребят, может кто-то захочет вместе работать над таким проектом?
Я бы делал через асинхронные сокеты.
Плюс вынес бы основные признаки сервера в интерфейс,а реализацию каждого сервера делал бы через абстрактную фабрику и фабричный метод.
неужели в винде появились асинхронные сокеты?
Ты не поверишь таки да msdn.microsoft.com/...(v=vs.110).aspx
а, вы об этом ...
а вы о чем то другом подумали?
о классическом бсдешном 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.
Артем Лемешев
Alexandr Barishenko
Vitaly Chernooky
Alexandr Barishenko
Valentin Nechayev
Beaver Green
Artyom Krivokrisenko
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів