Нужно организовать быструю и надежную передачу данных между клиентами и сервером, remoting не подходит — слишком прожерлив.
Какие механизмы работы с сокетами есть в .NET, порекомендуйте чтонить почитать.
Заранее спасибо
Тот кто знает не говорит, тот кто говорит не знает.
Сокеты и .NET
От:
Аноним
Дата:
06.09.06 23:28
Оценка:
Ну я вот использовал Структуры в качестве передаваемых данных, они всегда сериализуются и приходят целиком, а не ссылками как объекты (MBR), у которых к тому же вызов каждого свойства сопровождался обращением к серверу.... Это займет очень малое время передачи. Если критично не время, а объем, то можно зипить канал.
Могу порекомендовать
Маклин С., Нафтел Дж,, Уильяме К. Microsoft .NET Remoting
Есть еще статья на rsdn.ru, помоему так и называется "Технологии построения распределенных приложений в .NET"
Если каждый день узнавать что-то новое, то можно очень долго чему-нибудь учиться
Здравствуйте, AlEXoFo, Вы писали:
AEX>Ну я вот использовал Структуры в качестве передаваемых данных, они всегда сериализуются и приходят целиком, а не ссылками как объекты (MBR), у которых к тому же вызов каждого свойства сопровождался обращением к серверу.... Это займет очень малое время передачи. Если критично не время, а объем, то можно зипить канал. AEX>Могу порекомендовать
AEX>Маклин С., Нафтел Дж,, Уильяме К. Microsoft .NET Remoting
читал, это ремотинг, он прожерлив на время и память, интересует прямая работа с сокетами...
Тот кто знает не говорит, тот кто говорит не знает.
Подробно описана работа с сокетами на русском языке в книге ".NET Сетевое программирование для профессионалов" (Professional .NET Network Programming).
Сокеты и .NET
От:
Аноним
Дата:
08.09.06 18:05
Оценка:
>Streamer1, 07.09.06 02:47 > .. remoting не подходит — слишком прожерлив...
Думаю, что Вы не правы. Опыт показывает, что не remoting — сериализация объектов, вот на что стоит обратить внимание. Если в качестве параметра к удаленому методу использовать byte[], то скорость обмена будет задавать физический канал.
Здравствуйте, AlEXoFo, Вы писали:
AEX>Ну я вот использовал Структуры в качестве передаваемых данных
Глупость. Во-первых по сравнению с обменом по сети разницы между классами и структурами нет. Во-вторых все стандартные форматтеры работают через рефлекшен, а значит все структуры будут боксится. Так что использование классов , передаваемых по значению, в данном случае предпочтительнее.
В этом случае получается, что объект сериализуется на сервере, а потом десериализуется на клиенте и все вызовы свойств происходят на клиенте. При этом же клиент должен знать класс в который я десериализую? т.е. класс на сервере, тот же класс на клиенте.
А если я использую интерфейсы? я просто не хочу давать реализацию клиенту. И хочу чтобы клиент не обновлялся, если я перепишу реализацию на сервере.
Как мне тут обойтись? Или все равно, если я поставлю [Serializable] у моих классов, то избегу этой проблемы?
Хотя в принципе я как то реализовал одну вещь, вот такую:
Структуры... внутри вызова методов, которые должны принимаьб/отправлять данные непосредственно с/на сервер(а) я обращался к объекту, который всю работу общению с сервером брал на себя. А потом я со структурами долго мучался Вот тут наверное надо как раз и использовать классы, передаваемые по значению.
СПАСИБО, что натолкнул на мысль.
Но все же вопрос, как быть с интерфейсами? Стоит ли их вообще использовать в ремоутинге? Потому как интерфейсы позволяют мне создавать очень гибкую архитектуру приложения.
Если каждый день узнавать что-то новое, то можно очень долго чему-нибудь учиться
Здравствуйте, AlEXoFo, Вы писали:
AEX>В этом случае получается, что объект сериализуется на сервере, а потом десериализуется на клиенте и все вызовы свойств происходят на клиенте.
Да.
AEX> При этом же клиент должен знать класс в который я десериализую?
Да.
AEX> т.е. класс на сервере, тот же класс на клиенте.
Можно другой, но с совпадающим контрактом и именем.
AEX>А если я использую интерфейсы?
Не получится. Для передачи по значению нужна реализация.
AEX> я просто не хочу давать реализацию клиенту.
А в DTO и не должна соджержаться реализация. Только данные. Классы с реализацией должны передаваться по ссылке, иначе смысла в сервере приложений нет.
AEX>Но все же вопрос, как быть с интерфейсами? Стоит ли их вообще использовать в ремоутинге?
JIT>Подробно описана работа с сокетами на русском языке в книге ".NET Сетевое программирование для профессионалов" (Professional .NET Network Programming).
спасибо, а ссылочки на эл.вариант книги случайно нет?
Тот кто знает не говорит, тот кто говорит не знает.
Здравствуйте, Streamer1, Вы писали:
".NET Сетевое программирование для профессионалов" (Professional .NET Network Programming).
S>спасибо, а ссылочки на эл.вариант книги случайно нет?
На русском е-варианта не существует (я постоянно мониторю "нужные" сайты). Английский вариант легко ищется гуглом.