Передача данных через сокет

@Sierra26 · Регистрация: 04.06.2015

Студворк — интернет-сервис помощи студентам

Подскажите пожалуйста. Может быть кто-то разбирался с этим:
как лучше всего передавать данные через сокет, чтобы их легко обработать. Вариант есть пакетами с постоянным размером, но жалко передавать полупустые пакеты. Если передавать сколько нужно, то приемник не знает а сколько читать. Были мысли перед каждым пакетом передавать размер пакета. Может какие-то идеи еще есть. Очень бы хотелось почитать хорошую литературу по этому вопросу.

@Программер · 08.08.2018, 12:45

В каком смысле как лучше передавать данные? Что значит "лучше"? Ты какой проект делаешь?

@Sierra26 · 08.08.2018, 13:26 **[ТС]**

Программер, Сервер - клиент. Клиент посылает запрос (Что-то надо сделать) и Параметры (например имя файла приема). Сервер на этот запрос делает определенные действия (Передача файла, ответ клиенту и.д.р). Клиентов не один (до 30).

@Программер · 08.08.2018, 14:13

да это обычный клиент сервер прочитай в начале книги "Эффективное программирование сетевых приложений " Йон Снейдер

@CheshireCat · 08.08.2018, 16:01

А как ты собираешься передавать туда-сюда запросы и данные? По какому протоколу?

Существуют два основных протокола: UDP и TCP. Есть и другие, но они главным образом надстройки над упомянутыми.
Так вот, в протоколе UDP есть ограничение на размер "пакета", зато одна посылка - строго один "пакет". А самое главное - в UDP нет гарантии доставки "пакета". Отправитель отправил, а там - как Б.Г. даст

С другой стороны, в TCP есть гарантия доставки - то есть отправленная информация гарантированно будет доставлена получателю, либо ты получишь ошибку (разрыв соединения, либо таймаут, либо "получатель недоступен" или что-то еще). Но - в TCP не понятия "пакета". По TCP соединению передается поток ("лента") байтов, а как эти байты интерпретировать - определяется логическим протоколом взаимодействия отправителя и получателя.

@Sierra26 · 08.08.2018, 16:14 **[ТС]**

CheshireCat, забыл сказать. Протокол TCP. Вот как эту "ленту" обрабатывать?

@CheshireCat · 08.08.2018, 16:32

Дык, эта.... Писано ж русским по белому: "определяется логическим протоколом взаимодействия отправителя и получателя".

То есть сам по себе протокол TCP предоставляет тебе только транспортный уровень - гарантирует доставку "от и до". А вот поверх него тебе нужно сконструировать (или найти готовый) логический протокол взаимодействия клиента и сервера. В самой простой реализации - каждая посылка (безразлично, от клиента к серверу или наоборот) содержит "заголовок" и собственно "данные". Заголовок описывает назначение и - самое главное! - размер данных. То есть сначала сервер (или клиент) вычитывает из "потока" заголовок, и определяет - сколько нужно вычитать данных и что потом с этими данными делать? Ну а потом вычитывает данные и как-то их обрабатывает....

@Sierra26 · 08.08.2018, 16:59 **[ТС]**

CheshireCat"В самой простой реализации", если было так все просто. Если сокет блокирующийся, то один клиент заблокирует весь поток. Писать под каждого клиента свой поток (я считаю не рационально). На не блокирующийся сокете все гораздо хуже. Ожидаем данные их клиент не передал(затормозил) и все мы их не обработали. А следом приходят данные которые мы обрабатываем не как надо. Вот хотелось бы литературу про "определяется логическим протоколом взаимодействия отправителя и получателя"

@prik · 09.08.2018, 11:22

Сообщение от Sierra26;

если было так все просто. Если сокет блокирующийся, то один клиент заблокирует весь поток. Писать под каждого клиента свой поток (я считаю не рационально). На не блокирующийся сокете все гораздо хуже. Ожидаем данные их клиент не передал(затормозил) и все мы их не обработали. А следом приходят данные которые мы обрабатываем не как надо. Вот хотелось бы литературу про "определяется логическим протоколом взаимодействия отправителя и получателя"

Sierra26, Не понятно разделение на блокирующиеся/не блокирующиеся сокеты в контексте топика. И там и там вы должны ждать (просто копить полученные данные) пока не получите их достаточно для однозначной интерпретации, а где именно ждать, в recv() или в select()/poll()/etc дело десятое.

Книжку к сожалению не смогу порекомендовать, но советую для начала определиться со всякими "глобальностями" типа протокол будет двоичный или текстовый, синхронный или асинхронный и тд. А дальше переходить к более мелким деталям типа способы кодирования полей переменной длины.

@Sierra26 · 09.08.2018, 14:21 **[ТС]**

prik, разделение вот в чем: если сокет блокирующийся то он заблокирует весь поток. А вдруг от другого клиента пришло то что нужно, а мы ждем пока первый передаст нам данные. Я выше написал об этом

@prik · 09.08.2018, 14:39

Sierra26, я наверное, что-то не понимаю. У вас есть решение для одного клиента, и нужно поправить его для 30? Если нет, то повторюсь, в контексте вопроса "как передавать данные" это не важно. Если да, то в чем именно затык?

@CheshireCat · 09.08.2018, 15:02

Сообщение от Sierra26

В самой простой реализации", если было так все просто. Если сокет блокирующийся, то один клиент заблокирует весь поток. Писать под каждого клиента свой поток (я считаю не рационально).

На самом деле даже в "самой простой реализации" все еще интереснее

В серверной части: если запросы клиентов независимы и ответы сервера на них тоже независимы, то как раз целесообразно создавать по отдельному потоку на каждый запрос. Поток принимает запрос от клиента, как-то его обрабатывает (блок логики) и отсылает ответ, после чего тихо-мирно умирает. На новый запрос порождается новый поток. Ну или можно создать пул потоков и "черпать потоки" оттуда по мере надобности. Зависит от требуемой скорости обработки запросов.

А вот если запросы и ответы становятся взаимозависимыми..... Тут тебе не обойтись без пула потоков, которые будут принимать запросы и складывать их в общую очередь, которую будет разгребать уже отдельный поток (логики) с учетом взаимозависимости запросов....
А в клиентской части тоже целесообразно разделить и выполнять посылку/прием запросов и ответов в отдельном потоке, а GUI - в отдельном. Потому как после посылки запроса неизвестно, когда сервер нам ответит. А вдруг сеть оборвалась?

@prik · 09.08.2018, 15:36

Сообщение от CheshireCat

А вот если запросы и ответы становятся взаимозависимыми..... Тут тебе не обойтись без пула потоков

Почему не обойтись то? Классический пример SMTP.

@Sierra26 · 09.08.2018, 17:05 **[ТС]**

prik, Может посоветуйте литературу с примерами

@prik · 09.08.2018, 18:19

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

@Вованя · 16.08.2018, 04:29

Sierra26, TLV протокол, например.

Новые блоги и статьи Все статьи Все блоги /
http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .	http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит переходные токи и напряжения на элементах схемы. . . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .
Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189

	Передача данных через сокет 08.08.2018, 10:44. Показов 4303. Ответов 15 Метки нет (Все метки) Подскажите пожалуйста. Может быть кто-то разбирался с этим: как лучше всего передавать данные через сокет, чтобы их легко обработать. Вариант есть пакетами с постоянным размером, но жалко передавать полупустые пакеты. Если передавать сколько нужно, то приемник не знает а сколько читать. Были мысли перед каждым пакетом передавать размер пакета. Может какие-то идеи еще есть. Очень бы хотелось почитать хорошую литературу по этому вопросу. 0

@Программер 6 / 5 / 1 Регистрация: 06.09.2015 Сообщений: 176
	08.08.2018, 12:45
	В каком смысле как лучше передавать данные? Что значит "лучше"? Ты какой проект делаешь? 0

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189
	08.08.2018, 13:26 [ТС]
	Программер, Сервер - клиент. Клиент посылает запрос (Что-то надо сделать) и Параметры (например имя файла приема). Сервер на этот запрос делает определенные действия (Передача файла, ответ клиенту и.д.р). Клиентов не один (до 30). 0

@Программер 6 / 5 / 1 Регистрация: 06.09.2015 Сообщений: 176
	08.08.2018, 14:13
	да это обычный клиент сервер прочитай в начале книги "Эффективное программирование сетевых приложений " Йон Снейдер 0

@CheshireCat 2924 / 1274 / 114 Регистрация: 27.05.2008 Сообщений: 3,465
	08.08.2018, 16:01
	А как ты собираешься передавать туда-сюда запросы и данные? По какому протоколу? Существуют два основных протокола: UDP и TCP. Есть и другие, но они главным образом надстройки над упомянутыми. Так вот, в протоколе UDP есть ограничение на размер "пакета", зато одна посылка - строго один "пакет". А самое главное - в UDP нет гарантии доставки "пакета". Отправитель отправил, а там - как Б.Г. даст С другой стороны, в TCP есть гарантия доставки - то есть отправленная информация гарантированно будет доставлена получателю, либо ты получишь ошибку (разрыв соединения, либо таймаут, либо "получатель недоступен" или что-то еще). Но - в TCP не понятия "пакета". По TCP соединению передается поток ("лента") байтов, а как эти байты интерпретировать - определяется логическим протоколом взаимодействия отправителя и получателя. 0

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189
	08.08.2018, 16:14 [ТС]
	CheshireCat, забыл сказать. Протокол TCP. Вот как эту "ленту" обрабатывать? 0

@CheshireCat 2924 / 1274 / 114 Регистрация: 27.05.2008 Сообщений: 3,465
	08.08.2018, 16:32
	Дык, эта.... Писано ж русским по белому: "определяется логическим протоколом взаимодействия отправителя и получателя". То есть сам по себе протокол TCP предоставляет тебе только транспортный уровень - гарантирует доставку "от и до". А вот поверх него тебе нужно сконструировать (или найти готовый) логический протокол взаимодействия клиента и сервера. В самой простой реализации - каждая посылка (безразлично, от клиента к серверу или наоборот) содержит "заголовок" и собственно "данные". Заголовок описывает назначение и - самое главное! - размер данных. То есть сначала сервер (или клиент) вычитывает из "потока" заголовок, и определяет - сколько нужно вычитать данных и что потом с этими данными делать? Ну а потом вычитывает данные и как-то их обрабатывает.... 0

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189
	08.08.2018, 16:59 [ТС]
	CheshireCat"В самой простой реализации", если было так все просто. Если сокет блокирующийся, то один клиент заблокирует весь поток. Писать под каждого клиента свой поток (я считаю не рационально). На не блокирующийся сокете все гораздо хуже. Ожидаем данные их клиент не передал(затормозил) и все мы их не обработали. А следом приходят данные которые мы обрабатываем не как надо. Вот хотелось бы литературу про "определяется логическим протоколом взаимодействия отправителя и получателя" 0

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189
	09.08.2018, 14:21 [ТС]
	prik, разделение вот в чем: если сокет блокирующийся то он заблокирует весь поток. А вдруг от другого клиента пришло то что нужно, а мы ждем пока первый передаст нам данные. Я выше написал об этом 0

@prik 725 / 224 / 73 Регистрация: 01.03.2011 Сообщений: 643
	09.08.2018, 14:39
	Sierra26, я наверное, что-то не понимаю. У вас есть решение для одного клиента, и нужно поправить его для 30? Если нет, то повторюсь, в контексте вопроса "как передавать данные" это не важно. Если да, то в чем именно затык? 0

@Вованя 153 / 148 / 66 Регистрация: 20.02.2014 Сообщений: 556
	16.08.2018, 04:29
	Sierra26, TLV протокол, например. 0

@Sierra26 7 / 7 / 3 Регистрация: 04.06.2015 Сообщений: 189
	09.08.2018, 17:05 [ТС]
	prik, Может посоветуйте литературу с примерами 0

@prik 725 / 224 / 73 Регистрация: 01.03.2011 Сообщений: 643
	09.08.2018, 18:19
	Sierra26, Нет, к сожалению. Не встречал книги где-бы разбирали все возможные методы построения протоколов передачи данных. Сам бы почитал с удовольствием. Определитесь будет ли ваш протокол бинарным или текстовым. Для бинарного как правило применяются либо указание размера "сообщения", ну или его переменной части, либо заранее определенный набор пакетов + какой-либо признак позволяющий однозначно определить тип пакета ну и соответственно его размер. Для текстового обычно применяют, не указание длины, а терминацию. 0