[SetNet & Console Application] Первые шаги. SetNet.PeerBase. Часть 2

[nerzhul]

Каким образом происходит сериализация сообщений? Насколько оно производительно?
Если это обычная xml сериализация дотнета, то уж лучше взять и юзать signal.r.
Когда мы писали взаимодействие client-server для маленькой игрушки в универе, пришлось заюзать protocol buffers, вот это было реально быстро.
Как работет авторизация и есть ли она?
Есть ли возможность создавать типизированные сервисы?

Мне для текущего проекта нужна была библиотека, которая умела бы push модель с прозрачным процессом коннекта/дисконнекта клиентов, плюс строгая типизация сервисов. Лучше Signal.R пока ничего не нашел.

[nerzhul]

>Thread receivethread = new Thread(ReceiveThread);
Просто так создавать треды — очень плохая практика.
Юзайте ThreadPool.
void ReceiveThread()

        {
            while (true)
            {

                byte[] buffer = new byte[Configuration.bufferLenght];
                int read = client.Receive(buffer);
                if (read > 0)
                {
                    EventData data = Serialization.Deserializate(buffer);
                    if (data != null)
                    {
                        RecevieData(data);
                    }
                }

            }
        }

Потенциально огромный мемори траффик.

Вижу, что юзается бинари форматтер, для целей быстрой сериализации данных — он жутко медленный. ПРоверяли.

                 catch (SocketException ex)
                    {
                    }

За такое, особенно в либах, бьют палкой.

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

[Illivion]

Просто так создавать треды — очень плохая практика.
Юзайте ThreadPool.

Юзайте асинхронные методы, поддерживаемые на уровне ОС.

[nerzhul]

Что вы имеете в виду под асинхронными методами и поддерживаемостью со стороны ОС?

[OpenMinded]

Посмотрел код. Могу посоветовать следующее: посмотреть в сторону асинхронных методов у сокетов и в частности на SockenAsyncEventArgs. Dependency injection для Serialization и Configuration как минимум. Разделение TCP и UDP кода. Между ними принципиальная разница и if в каждом методе именно из-за этого. Также, насколько я вижу, не учтена ситуация, когда отправленный TCP пакет придет в виде двух пакетов или наоборот несколько пакетов объединятся по пути. Это редкая ситуация, но ее нужно учесть.

[Holms]

А не посоветуйте либу со всеми что вы написали для C#?
Особенно где учитывается

Также, насколько я вижу, не учтена ситуация, когда отправленный TCP пакет придет в виде двух пакетов или наоборот несколько пакетов объединятся по пути.

Спасибо

[OpenMinded]

Я для таких целей когда-то свой велосипед пробовал писать. Но то было для конкретного протокола — HTTP. Выделение сообщений из стрима TCP сильно зависит от протокола. Это может быть постоянная длина сообщений, префикс из пары байт с размером сообщения, байты-делимитеры и различные комбинации всего этого. Все это может сильно повлиять на код парсера-сериализации.

[Holms]

так в том и проблема, что велосипеды все пишут :)
А что-то готового нету, как например либа Nio для Java.
Для себя я тоже велосипед написал, но хочется чего то лучшего, проверенного временем и другими разработчиками.

[kovyl]

Я извиняюсь, конечно. Автор, до этого, вообще с сетью работал? Ну хоть раз?