Библиотеки для работы с Асинхронными Сокетами?

Question

[OwDafuq]

Добрый день/вечер/ночь/утро.

Собственно все что нужно - в тайтле.

p.s. - NetSockets не предлагать.

p.s.s. - Поиск таких библиотек оказался безуспешный.

p.s.s.s. - Хотелось бы функционал как в NetSockets.

Comments

[#алгоптимизируй #отботизируй]

сокет из коробки вроде и так асинхронный

[OwDafuq]

#алгоптимизируй: нет

Answer 1

[Rou1997]

Собственно все что нужно - в тайтле.

Нет, не все. Никакой конкретики о требованиях к библиотеке.
TCP/IP - это 80-е годы прошлого века и с тех пор они почти не развились, поэтому многое не входит в сам протокол и по-прежнему реализуется разработчиком приложения или библиотеки. А если по факту не реализуется, то и не работает, это я на всякий случай. Вроде все просто, что тут хитрого - Read да Write, вроде все сделали, вроде проверили, вроде работает, туда-сюда, но не успело пройти пару часов - как бац - и сервер "упал" в Exception вместе с вашим гонораром за работу!

Оно у вас хотя бы через интернет будет, или в локальной сети?
Это уже две большие разницы.
Клиент либо сервер должен ли работать 24/7, или запустили сервер, запустили клиент, отправили что-то туда-обратно и через 15 минут оба завершали?

Ну а так, я вам могу и AwesomeSockets посоветовать, они и синхронные и асинхронные сообщения поддерживают, только толку от них никакого, ни надежности, ни удобства разработки, да и у вас бы на написание аналогичной библиотеки ушло бы не больше недели на все-про-все.

Из серьезного - смотрите SuperSocket и WCF, но еще раз, сперва сформулируйте задачу.

Comments

[OwDafuq]

1. Будет работать через интернет
2. Клиент и сервер должны работать 24\7 (ну как минимум сервер)

Чем не нравится мне NetSockets, так это тем, что клиент у него немного баганый, если отправлять подряд несколько данных, то они придут не все.

[Rou1997]

LiptonOlolo:
Если через интернет, то еще и о защите от ботов позаботьтесь на сервере, а также нужна защита от неполадок с сетью которые в интернете достаточно часты: все пакеты должны идти с заголовком из хеш-суммы и размера, на отправляющей стороне нужно предусмотреть обрыв соединения при вызове Write (там Exception, если Write на клиенте то просто заново пробуйте подключиться и затем повторно отправляйте пакет), а также повреждение пакетов если обрыв произойдет уже в процессе отправки то единственный способ клиенту об этом узнать - это получить ответ от сервера, в котором сервер либо скажет что все ОК и тогда пакет считайте отправленным, либо попросит повторно отправить пакет, и учтите что этот ответ тоже вполне может оказаться поврежденным, значит и его нужно проверять и если надо перезапрашивать, и так должно быть зациклено до тех пор, пока не придет правильный, и еще во всех этих этапах на клиенте не забывайте про Connect, который может потребоваться в catch как при Write так и при Read. И про банальные KeepAlive/HeartBeat не забывайте, иначе через 2 часа клиент сам отключится.
Это алгоритм в целом, если используете библиотеку то убедитесь что в ней все это есть, а если нет, то либо реализуйте сами поверх нее, либо откажитесь от нее вовсе.
Для тестирования используйте программу типа NetLimiter, а также большие пакеты чтобы было время, и вручную либо программно отключайте сеть.

клиент у него немного баганый, если отправлять подряд несколько данных, то они придут не все.

Может это и не баг, а просто отсутствие реализации чего-то из вышеописанного.

В общем, дело совсем не простое.