0 / 0 / 0
Регистрация: 06.04.2014
Сообщений: 6
|
|||||||||||
1 | |||||||||||
Передача данных от клиента к серверу19.11.2016, 20:04. Показов 1780. Ответов 7
Метки нет (Все метки)
Всем привет!
Возникла потребность передавать данные по симметрично-шифрованному соединению. Клиент передает данные(в данном случае число double), сервер принимает. Можно и наоборот - суть не меняется. Проблема в том, что после первой передачи ничего не принимается, после второй - прием первой, после третьей - вторая и т.д. Получить данные без задержки можно, если сразу после передачи закрыть стрим, но это рвет соединение, а на этом этапе не хотелось бы. Вот сервер
0
|
19.11.2016, 20:04 | |
Ответы с готовыми решениями:
7
Передача архива от клиента к серверу Передача двух переменных разного типа с клиента серверу Ошибка при сериализации от клиента серверу Кривая отправка сообщений клиента серверу |
0 / 0 / 0
Регистрация: 06.04.2014
Сообщений: 6
|
|
19.11.2016, 22:42 [ТС] | 3 |
insite2012, более подходящей темы не нашел. На счет wcf подумаю, спасибо за совет, но вопрос не снят, хотелось бы разобраться.
0
|
11 / 11 / 4
Регистрация: 03.07.2014
Сообщений: 28
|
|
20.11.2016, 14:58 | 4 |
mishgan2, для сетевого взаимодействия на сокетах управляемых вручную, это нормальное явление отправлять данные в момент когда они сами решили (например при заполнении своего внутреннего буфера). Кроме этого они ещё способны разбивать ваши данные на более мелкие части. Одним из решений является добавление в ваш пакет данных заголовка и окончания пакета.
0
|
0 / 0 / 0
Регистрация: 06.04.2014
Сообщений: 6
|
||||||
20.11.2016, 15:56 [ТС] | 5 | |||||
ivankon, Правильно ли я понимаю, что данные окончания пакета создаются закомментированной строчкой в примере моего клиента - CryptStreamWriter.FlushFinalBlock();? Но это же для CryptStreamWriter одноразовая операция.
Как после закрытия пакета наиболее корректно возобновить передачу? Я пробовал обновлять CryptStreamWriter через new, но не получается, CryptStreamReader на обратной стороне начинает расшифровывать неверно, хотя ключи не менялись. Добавлено через 5 минут Может не очень понятно написал, вот цикл клиента, который передает данные серверу:
На первой итерации в строке 9 создаем CryptStreamWriter впервые. Отправляем, и затем флушим финальный блок (стрка 11). Отлично, все ушло сразу, как я и хотел. На принимающей стороне корректно расшифровалось. Но CryptStreamWriter теперь уже не рабочий. Поэтому на второй итерации мы снова его пересоздаем в строке 9. Отправляем, флушим - все ушло! Но со второго раза принимающий ридер начинает расшифровывать не корректно.
0
|
11 / 11 / 4
Регистрация: 03.07.2014
Сообщений: 28
|
|
20.11.2016, 17:00 | 6 |
ну я правда немного не об этом говорил)
В таком случае, вам нужно попробовать пересоздать принимающий ридер. Добавлено через 6 минут И ещё... не отказывайтесь от совета про WCF. Дело в том что, начав его изучать только вчера, вы уже решили бы эту задачу и могли бы двигаться дальше в ваших задумках.
1
|
0 / 0 / 0
Регистрация: 06.04.2014
Сообщений: 6
|
|
20.11.2016, 17:39 [ТС] | 7 |
ivankon, спасибо, пересоздавать ридер помогло. Скажите, правильно ли я понимаю, что WCF значительно более ресурсоемкая затея, нежели то, что в моих примерах. Мне просто нужно что-то максимально шустрое и легковесное, но с защитой от перехвата трафика. Задача-мониторить процессы, происходящие на сервере, отнимая как можно меньше ресурсов. WCF, как мне кажется, будет несколько тяжеловат.. Или я в корне неправ?
0
|
11 / 11 / 4
Регистрация: 03.07.2014
Сообщений: 28
|
|
20.11.2016, 18:03 | 8 |
По поводу производительности WCF против аналогичного кода ничего не могу сказать, т.к. написать аналогичный по функционалу код весьма не просто. Но есть несколько моментов которые возможно помогут вам с выбором:
1. библиотеки WCF (System.ServiceModel) после установки net, хранятся в GAC (Глобальный Кэш Сборок), в скомпилированном в машинный код виде (это по словам МС увеличивает скорость первого запуска на 60%)(Пусть меня поправят более опытные программисты, если я не прав) 2. с помощью WCF очень легко создать асинхронный сервер, в вашем случае я так понял будет синхронный сервер, что отнимет у ОС лишние потоки (а это весьма ценный ресурс для сервера), т.к. пул потоков приложения создаст дополнительный поток взамен ожидающего в блокировке 3. на WCF легко можно организовать передачу по нескольким каналам больших объёмов данных, для того чтобы занять всю полосу пропускания, на сокетах это сделать весьма утомительно (я делал, получилось не очень...)
1
|
20.11.2016, 18:03 | |
20.11.2016, 18:03 | |
Помогаю со студенческими работами здесь
8
Реализация клиента для подключения к серверу на WebSocket Необработанное исключение при подключении клиента к серверу Socket Server/Client. Падение клиента при коннекте к серверу Как отловить подсоединение нового клиента к серверу на базе UDP Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |