Comments 9
Буду благодарен за конструктивную критику, просто я немного сконфужен, с одной стороны в избранное добавляют, соответственно статья имеет право на жизнь, с другой, большое количество минусов.
Спасибо!
Спасибо!
Половина статьи состоит из описания сериализатора. Далее вполне обычная работа с TcpClient/TcpListener, которая в msdn довольно подробно описана.
Пула коннектов (с пересоединением для балансировки) не хватает.
Из конструктивного — WCF же.
//считываем из потока длину строки
command.StringFieldLenght = br.ReadInt32();
Пула коннектов (с пересоединением для балансировки) не хватает.
Из конструктивного — WCF же.
>Из конструктивного — WCF же.
WCF не всегда возможен / удобен, особенно если речь идет о разных платформах / языках программирования.
>Пула коннектов (с пересоединением для балансировки) не хватает.
Это правда, пример из статье не годится в промышленное применение или просто в проект с высокой нагрузкой.
>Половина статьи состоит из описания сериализатора. Далее вполне обычная работа с TcpClient/TcpListener, которая в msdn довольно подробно описана.
В свое время я потратил довольно прилично времени, чтобы это все написать и исправить все найденные ошибки, поэтому и решил написать статью с работающим примером, чтобы кто-то воспользовался результатами моей работы и сэкономил себе время.
WCF не всегда возможен / удобен, особенно если речь идет о разных платформах / языках программирования.
>Пула коннектов (с пересоединением для балансировки) не хватает.
Это правда, пример из статье не годится в промышленное применение или просто в проект с высокой нагрузкой.
>Половина статьи состоит из описания сериализатора. Далее вполне обычная работа с TcpClient/TcpListener, которая в msdn довольно подробно описана.
В свое время я потратил довольно прилично времени, чтобы это все написать и исправить все найденные ошибки, поэтому и решил написать статью с работающим примером, чтобы кто-то воспользовался результатами моей работы и сэкономил себе время.
Замечание 1:
Заголовок статьи не соответствует содержимому. Я, посмотрев на заголовок и преамбулу, подумал, что речь пойдёт о своём сокетном велосипеде. Даже подумать не мог, что здесь свой RPC изобретается.
Замечание 2: В статье был изобретён свой RPC-велосипед, но при этом протокол не был описан, и его пришлось выуживать из исходников.
Кстати, я вот что-то не припомню, инты BinaryReader читает/пишет в big endian или little endian? Такие вещи нужно обязательно описывать.
Замечание 3: Не понятно, почему вместо сериализации, нужно было руками байты вытаскивать. Команд может быть очень много, и в процессе их ручной сериализации вы очень быстро начнёте делать ошибки.
Замечание 4: Допустим, я — хакер. В процессе поиска дырочек, я перебираю все найденные порты, отправляя на них стандартный HTTP Get. Что произойдёт?
Вот эта строка на нехорошие мысли наводит:
Заголовок статьи не соответствует содержимому. Я, посмотрев на заголовок и преамбулу, подумал, что речь пойдёт о своём сокетном велосипеде. Даже подумать не мог, что здесь свой RPC изобретается.
Замечание 2: В статье был изобретён свой RPC-велосипед, но при этом протокол не был описан, и его пришлось выуживать из исходников.
Кстати, я вот что-то не припомню, инты BinaryReader читает/пишет в big endian или little endian? Такие вещи нужно обязательно описывать.
Замечание 3: Не понятно, почему вместо сериализации, нужно было руками байты вытаскивать. Команд может быть очень много, и в процессе их ручной сериализации вы очень быстро начнёте делать ошибки.
Замечание 4: Допустим, я — хакер. В процессе поиска дырочек, я перебираю все найденные порты, отправляя на них стандартный HTTP Get. Что произойдёт?
Вот эта строка на нехорошие мысли наводит:
CommandHeader commandHeader = CommandHeader.FromBytes(bytes);
Спасибо за комментарий, отвечу по пунктам:
>Заголовок статьи не соответствует содержимому.
На мой взгляд вполне соответствует.
>Я, посмотрев на заголовок и преамбулу, подумал, что речь пойдёт о своём сокетном велосипеде
Это и есть свой велосипед.
> В статье был изобретён свой RPC-велосипед
RPC — Remote Procudure Call, ничего такого у меня нет, просто отправка и прием команд с подробным описанием, хотя, возможно все таки описание не достаточно подробное.
>Кстати, я вот что-то не припомню, инты BinaryReader читает/пишет в big endian или little endian
Если я правильно помню, .net работает с little endian порядком. Если же вы хотите взаимодействовать с Java, то необходимо разворачивать порядок байт, я об этом упомянул в конце статьи.
>Замечание 3: Не понятно, почему вместо сериализации, нужно было руками байты вытаскивать. Команд может быть очень много, и в процессе их ручной сериализации вы очень быстро начнёте делать ошибки.
Вы правы, логичнее было бы сделать автоматический сериализатор, но я сделал именно так как сделал.
>Замечание 4: Допустим, я хакер. В процессе поиска дырочек, я перебираю все найденные порты, отправляя на них стандартный HTTP Get. Что произойдёт?
Это не понял, причем тут хакер и http get?
>Вот эта строка на нехорошие мысли наводит: CommandHeader commandHeader = CommandHeader.FromBytes(bytes);
Поясните, что именно смутило?
>Заголовок статьи не соответствует содержимому.
На мой взгляд вполне соответствует.
>Я, посмотрев на заголовок и преамбулу, подумал, что речь пойдёт о своём сокетном велосипеде
Это и есть свой велосипед.
> В статье был изобретён свой RPC-велосипед
RPC — Remote Procudure Call, ничего такого у меня нет, просто отправка и прием команд с подробным описанием, хотя, возможно все таки описание не достаточно подробное.
>Кстати, я вот что-то не припомню, инты BinaryReader читает/пишет в big endian или little endian
Если я правильно помню, .net работает с little endian порядком. Если же вы хотите взаимодействовать с Java, то необходимо разворачивать порядок байт, я об этом упомянул в конце статьи.
>Замечание 3: Не понятно, почему вместо сериализации, нужно было руками байты вытаскивать. Команд может быть очень много, и в процессе их ручной сериализации вы очень быстро начнёте делать ошибки.
Вы правы, логичнее было бы сделать автоматический сериализатор, но я сделал именно так как сделал.
>Замечание 4: Допустим, я хакер. В процессе поиска дырочек, я перебираю все найденные порты, отправляя на них стандартный HTTP Get. Что произойдёт?
Это не понял, причем тут хакер и http get?
>Вот эта строка на нехорошие мысли наводит: CommandHeader commandHeader = CommandHeader.FromBytes(bytes);
Поясните, что именно смутило?
Раз статья о довольно низкоуровневой работе с сокетами, то, возможно, есть смысл детальнее описать сам протокол и как вы решили сами проблемы буферизации и полинга данных?
Sign up to leave a comment.
Cетевое взаимодействие посредством TCP в C# — свой велосипед