Socket: Client & Server

@sitesv · Регистрация: 22.04.2010

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

Нужен квалифицированный совет!
Существует устройство, на котором стоит ОС Linux.
Это устройство соединено с ПК с Win.
Это устройство с ОС Линукс должно отдавать постоянно данные на ПК, но при помощи приложения на ПК оно еще должно управляться.
Используя сокеты, написан сервер на "С" под Линукс и Клиент на "С++" под Win на ПК. Но чувствую что этого недостаточно.
Как я понял, сервер не может осуществлять постоянную передачу данных, кроме ответных сообщений на запрос от клиента. Если не прав - поправьте меня.
Т.е., как я догадываюсь, нужно реализовывать на обоих машинах и сервер и клиент? Клиент под Линукс нужен чтобы постоянно отправлять данные от устройства серверу на ПК, а сервер ПК будет подтверждать прием данных, сервер под линукс нужен чтобы принимать запросы от клиента из Win (ПК) на упраление (изменение параметров устройства).
Правильные мысли? Или можно сделать проще?

Evg · 21.05.2010, 12:34

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

т.е. коннект заблокируется

Никак. connect - это одноразовое действие. Либо смогли, либо не смогли. Если не смогли, то это забота программы запускать connect до тех пор, пока не сможем

@sitesv · 22.05.2010, 13:30 **[ТС]**

Столкнулся с проблемой...
Передаю данные используя TCP протокол.
Размер поля данных в TCP протоколе составляет примерно 1400 байт.
Но, если у меня файл, который надо передать около 2 мб и его нарезаю по 1024 байт, то передача его затягивается секунд на 25-30 (эксперимент ставлю на одной машине, используя IP 127.0.0.1). Как увеличить скорость передачи данных? Ведь если нарезать файл на бОльшие куски, то размер данных за один раз на входе не будет всегда соответствовать размеру переданных за один раз данных. Только когда результирующие данные на входе будут =0, то файл успешно будет принят. А как например чтоб всегда было, что 1 раз отправил 100 кб - и за один раз принялось 100 кб...? Бывает ситуация, что на входе не за один раз принимаются 100 кб, а например за 2 раза, 25 кб в первый раз и 75 кб во второй... Есть возможность избежать такое?

@fasked · 22.05.2010, 13:38

А ты уверен что проблема именно в сокетах? может быть ты файлы "нарезаешь" неоптимальным способом, потому что когда я передавал кусками по 512 байт по лупбэку у меня за 20-25 секунд уходили файлы куда большего размера, больше 1Гб точно

Добавлено через 2 минуты
В любом случае фрагментация пакетов идет на другом уровне и думаю не так значимо, тем более значение MTU как правило равно 1500

@sitesv · 22.05.2010, 13:45 **[ТС]**

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

может быть ты файлы "нарезаешь" неоптимальным способом

нарезаю по 1024 байта + 21 байт заголовок мой...

Добавлено через 1 минуту
А как оптимально нарезать?

@fasked · 22.05.2010, 15:09

fread - дл Си
istream::read - Си++
Многие ведь могут и посимвольно додуматься читать

@sitesv · 23.05.2010, 12:56 **[ТС]**

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

fread - дл Си
istream::read - Си++

а это тут причем? Читаю файл в билдере через FileRead

Добавлено через 2 часа 39 минут
Происследовав чисто клиентскую часть, прихожу к выводу что у меня медленно передаются данные из одного потока в другой.
В одном потоке формирую заголовок+1024байта, кладу в массив, сдвигаю указатель записи...
В другом потоке сравниваю указатель чтения с указателем записи, и если есть отличие, то считываю из массива.
В такой ситуации и получается, что 2мб по 1045 байт передаются почти 30 секунд... Хрень какая-то....

В конце каждого цикла потоков ставлю Sleep(1), чтобы процессор не слишком перегружался...

Добавлено через 13 часов 33 минуты
Меня всегда учили в конце каждого цикла в потоке ставить sleep(1), из-за этого долго и передавались данные из одного потока в другой и соответственно передавались на сервер)) но, убрав слипы, процессор ушел почти на 100%, неужто надо ставить флаги (метки), чтобы при передачи обходить слип?

Evg · 23.05.2010, 18:07

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

Меня всегда учили в конце каждого цикла в потоке ставить sleep(1)

Кто тебя так учил, а главное - зачем?

@sitesv · 23.05.2010, 20:19 **[ТС]**

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

Кто тебя так учил, а главное - зачем?

Если работают потоки, без слипов, и программа находится к примеру в режиме ожидания, а процессор перегружен, вот зачем... не так ли?

Добавлено через 1 час 38 минут
Есть некоторое сомнение...
Например, клиент, в потоке постоянно осуществляет передачу данных серверу, через select проверяю доступность сокета для передачи...

Сервер в потоке пытается считать эти данные... например со стороны сервера процессор неособо мощный, т.е. скорость работы потока на сервере ниже чем на клиенте... не будет ли потери данных при приеме?
Сколько отправишь столько же и примешь? либо есть какая-то максимальная очередь? Что-то очень волнует этот вопрос...

Evg · 23.05.2010, 20:50

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

т.е. скорость работы потока на сервере ниже чем на клиенте... не будет ли потери данных при приеме?

Потерь данных не будет. В том и смысл TCP, что на каждый посланный пакет должно быть подтверждение (всё это на уровне ОС). Если сервер тормозит, то твоя программа будет относительно много времени проводить внутри select'а (т.е. проводить время внутри ОС, а значит твоя программа грузить процессор не будет)

@sitesv · 23.05.2010, 20:56 **[ТС]**

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

то твоя программа будет относительно много времени проводить внутри select'а

Время нахождение внутри селекта мы же сами задаем..
А как решается вопрос по поводу потоков и Sleep() и загрузкой процессора?

Evg · 23.05.2010, 21:10

Поток он либо должен работать, либо нет. Потоки создают по двум причинам:
- для увеличения скорости вычисления за счёт распараллеливания. Если на машине имеется как минимум 2 процессора или ядра
- чтобы ВИЗУАЛЬНО не тормозил пользоватльеский интерфейс. Принцип работы gui должен ыражаться в том, что пользователь куда-то нажал и сразу же без тормозов получил ответное действие, после чего программа опять уходит в спящий режим до следующего действия пользователя (нажатия на кнопку или мышку). Если реакция на действие имеет долгое время работы, то без потоков на время этой самой работы gui как бы висит. Чтобы этого не было, длительное действие выносят в поток. При этом либо поток сам отобразит свои данные, либо в главном процессе по таймеру происходит событие, которое опрашивает поток, и по его завершении информацию обновляет главный процесс.

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

@sitesv · 23.05.2010, 21:23 **[ТС]**

Мысль понял... Но, у меня немного структура другая... По нажатию на клавиши я не создаю новый поток, а просто работаю с флагами внутри созданного с момента запуска программы потока, а в нем постоянно опрашиваются эти флаги. В потоке у меня набор функционала под разные задачи, но они вызываются по разным флагам... Например читка файла... Реализована в потоке... я создал этот поток, в него всунул while, чтоб он постоянно работал... в конце while ставлю sleep(1), Вот если читать по 1 кб 1Гб файл и не поставить этот злополучный sleep(1), то проц будет перегружен. Ты понимаешь поток как однократное выполнение каких-либо функций и его закрытие, а я создаю поток (потоки) для их постоянной работы с момента запуска программы.

Evg · 23.05.2010, 22:45

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

Вот если читать по 1 кб 1Гб файл и не поставить этот злополучный sleep(1), то проц будет перегружен

И как это ты определяешь? Может проц загружен твоими очередными мегаконцептуальными кодами, а не посылкой данных по сети? Или попробуй слать кусками по 100 кбайт (без sleep'а), а ос внутри себя разберётся

@sitesv · 23.05.2010, 23:13 **[ТС]**

нет, не отправка вызывает перегрузку, а считывание из файла и всякие операции между массивами.
Отправляю по 1045 байт, на приемной стороне может быть 430+615, а как сделать так, чтобы на входе было только по 1045 байт?

Evg · 23.05.2010, 23:14

Три раза прочитал - ничо не понял

@sitesv · 24.05.2010, 09:29 **[ТС]**

Второе предложение было уже о другом)) Извини)
Вот, с клиента на сервер к примеру за один раз отправляю 1045 байт, а на сервере приходят сначала 430 байт, а во второй раз оставшиеся 615 байт. Как сделать так, чтобы не было этих двух раз, а был один и объем принятого сообщения равнялся 1045 байт?

Добавлено через 10 часов 13 минут

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
char optval_set_rcvbuf[4]={21,4,0,0};    //размер входных данных 1045 байт
char optval_set_sndbuf[4]={21,4,0,0};    //размер исходящих данных 1045 байт
optlen_set_rcvbuf=sizeof(optval_set_rcvbuf);
optlen_set_sndbuf=sizeof(optval_set_sndbuf);
if ((setsockopt(s, SOL_SOCKET, SO_SNDBUF, optval_set_sndbuf, optlen_set_sndbuf)) == SOCKET_ERROR)
{
   WSACleanup();
   return;
}
if ((setsockopt(s, SOL_SOCKET, SO_RCVBUF, optval_set_rcvbuf, optlen_set_rcvbuf)) == SOCKET_ERROR)
{
   WSACleanup();
   return;
}

МУЖИКИ!!! Ставлю одинаковый код как на сервере, так и на клиенте, но все равно, бывает на вход сервера приходит и 2!!! куска (к примеру 625+420байт или 205+840байт итд), вместо одного в 1045 байт.. не знаю уже как бороться...((( в setsockopt на return не попадает, т.е. он срабатывает...

@fasked · 24.05.2010, 14:05

Для управления потоками передачи данных (не теми потоками, которые создаешь ты) протокол TCP исопльзует специальный алгоритм, именуемый "скользящее окно". Суть его в том, что отправителю не обязательно дожидаться подтверждения приема со стороны получателя всех отправляемых данных. Протоколом TCP формируется подтверждение не для каждого успешно принятого пакета, а для некоторого количества отмечаемого порядковым номером ACK SN. Это количество может в процессе передачи меняться (отсюда и название "скользящее"). Алгоритм сам распределяет количество передаваемых данных, оптимизирует это количестве на основе анализа сети. То есть число переданных пакетов не обязательно сразу будет равно числу принятых пакетов. А ты по моему опять же пытаешься лезть на слишком низкий уровень. И опять же такой "простой" в работе сети не будет и заметен пользователю. Я никак не пойму с чего ты решил, что тормоза в передаче обусловлены именно самим процессом отправки/приема данных. К тому же если ты пользуешься не стандартными классами для чтения файлов, почему не воспользоваться уже разработанными кем-то классами сокетов. В Билдере насколько я могу помнить это TClientSocket и TServerSocket.

@sitesv · 24.05.2010, 20:25 **[ТС]**

В билдере есть эти классы, только в линуксе нет... Вот и приходится, чтобы наладить общение между виндой и линуксом, который установлен на микросхеме, работать на таком уровне с сокетами... Чтобы решить свою проблему с разбиением пришлось добавить функцию сегментации, которая собирает все данные приходящие от клиента в пакеты по 1045 байт... иначе никак не получилось... теперь все работает! А тормоза, я же уже писал выше, возникают не из-за передачи данных, а из-за моих слипов в потоках (TThread), которые давали возможность не перегружать процессор машины при непрерывном чтении большого файла... Для чтения из файла, передачи в другой поток этих данных и последующей передачи этого файла я убрал эти слипы, теперь все шуршит. Слипы вновь влючаются, когда программа находится в ждущем режиме или выполняются другие нересурсоемкие операции.
Спасибо за ликбез по TCP)

@fasked · 24.05.2010, 21:00

Не по теме:

Однако, умение грамотно выражать свои мыслит это талант

Evg · 24.05.2010, 23:44

fasked, жирный +1.

Новые блоги и статьи Все статьи Все блоги /
Отправка уведомления на почту при изменении наименования справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере изменения наименования типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .	SDL3 для Desktop (MinGW): Вывод текста со шрифтом TTF с помощью библиотеки SDL3_ttf на Си и C++ 8Observer8 24.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-text-sdl3-c. zip finish-text-sdl3-cpp. zip
Жизнь в неопределённости kumehtar 23.03.2026 Жизнь — это постоянное существование в неопределённости. Например, даже если у тебя есть список дел, невозможно дойти до точки, где всё окончательно завершено и больше ничего не осталось. В принципе,. . .	Модель здравоСохранения: работники работают быстрее после её введения. anaschu 23.03.2026 geJalZw1fLo Корпорация до введения программа здравоохранения имела много невыполненных работниками заданий, после введения программы количество заданий выросло. Но на выплатах по больничным это. . .	Контроль уникальности заводского номера Maks 23.03.2026 Алгоритм контроля уникальности заводского (или серийного) номера на примере нетипового документа выдачи шин для спецтехники с табличной частью, разработанного в конфигурации КА2. Данные берутся из. . .	Хочу заставить корпорации вкладываться в здоровье сотрудников: делаю мат модель здравосохранения anaschu 22.03.2026 e7EYtONaj8Y Z4Tv2zpXVVo https:/ / github. com/ shumilovas/ med2. git

@sitesv 27 / 25 / 5 Регистрация: 22.04.2010 Сообщений: 772

	Socket: Client & Server 11.05.2010, 22:15. Показов 16322. Ответов 86 Метки нет (Все метки) Нужен квалифицированный совет! Существует устройство, на котором стоит ОС Linux. Это устройство соединено с ПК с Win. Это устройство с ОС Линукс должно отдавать постоянно данные на ПК, но при помощи приложения на ПК оно еще должно управляться. Используя сокеты, написан сервер на "С" под Линукс и Клиент на "С++" под Win на ПК. Но чувствую что этого недостаточно. Как я понял, сервер не может осуществлять постоянную передачу данных, кроме ответных сообщений на запрос от клиента. Если не прав - поправьте меня. Т.е., как я догадываюсь, нужно реализовывать на обоих машинах и сервер и клиент? Клиент под Линукс нужен чтобы постоянно отправлять данные от устройства серверу на ПК, а сервер ПК будет подтверждать прием данных, сервер под линукс нужен чтобы принимать запросы от клиента из Win (ПК) на упраление (изменение параметров устройства). Правильные мысли? Или можно сделать проще? 1

@sitesv 27 / 25 / 5 Регистрация: 22.04.2010 Сообщений: 772
	22.05.2010, 13:30 [ТС]
	Столкнулся с проблемой... Передаю данные используя TCP протокол. Размер поля данных в TCP протоколе составляет примерно 1400 байт. Но, если у меня файл, который надо передать около 2 мб и его нарезаю по 1024 байт, то передача его затягивается секунд на 25-30 (эксперимент ставлю на одной машине, используя IP 127.0.0.1). Как увеличить скорость передачи данных? Ведь если нарезать файл на бОльшие куски, то размер данных за один раз на входе не будет всегда соответствовать размеру переданных за один раз данных. Только когда результирующие данные на входе будут =0, то файл успешно будет принят. А как например чтоб всегда было, что 1 раз отправил 100 кб - и за один раз принялось 100 кб...? Бывает ситуация, что на входе не за один раз принимаются 100 кб, а например за 2 раза, 25 кб в первый раз и 75 кб во второй... Есть возможность избежать такое? 0

@fasked 5045 / 2624 / 241 Регистрация: 07.10.2009 Сообщений: 4,310 Записей в блоге: 5
	22.05.2010, 13:38
	А ты уверен что проблема именно в сокетах? может быть ты файлы "нарезаешь" неоптимальным способом, потому что когда я передавал кусками по 512 байт по лупбэку у меня за 20-25 секунд уходили файлы куда большего размера, больше 1Гб точно Добавлено через 2 минуты В любом случае фрагментация пакетов идет на другом уровне и думаю не так значимо, тем более значение MTU как правило равно 1500 0

@fasked 5045 / 2624 / 241 Регистрация: 07.10.2009 Сообщений: 4,310 Записей в блоге: 5
	22.05.2010, 15:09
	fread - дл Си istream::read - Си++ Многие ведь могут и посимвольно додуматься читать 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	23.05.2010, 21:10
	Поток он либо должен работать, либо нет. Потоки создают по двум причинам: - для увеличения скорости вычисления за счёт распараллеливания. Если на машине имеется как минимум 2 процессора или ядра - чтобы ВИЗУАЛЬНО не тормозил пользоватльеский интерфейс. Принцип работы gui должен ыражаться в том, что пользователь куда-то нажал и сразу же без тормозов получил ответное действие, после чего программа опять уходит в спящий режим до следующего действия пользователя (нажатия на кнопку или мышку). Если реакция на действие имеет долгое время работы, то без потоков на время этой самой работы gui как бы висит. Чтобы этого не было, длительное действие выносят в поток. При этом либо поток сам отобразит свои данные, либо в главном процессе по таймеру происходит событие, которое опрашивает поток, и по его завершении информацию обновляет главный процесс. Во втором случае наличие 2 процессоров/ядер вовсе не нужно, т.к. это не более чем технический приём: операционная система всё равно по очереди исполняет оба потока, но зато не имеем визуальных тормозов. В этом втором случае скорость исполнения из-за наличия потоков практически не изменяется (чуть быстрее на многопроцессорных системах, чуть медленнее на однопроцессорных). Поэтому работать с потоком надо ровно так, как бы ты работал, будь это один процесс: т.е. без всяких sleep'ов. Не говоря уже о том, что скорость прокачки данных по сети на несколько порядков медленнее работы процессора, а потому отправка пакета по сети процессор почти никак не нагружает 0

@sitesv 27 / 25 / 5 Регистрация: 22.04.2010 Сообщений: 772
	23.05.2010, 21:23 [ТС]
	Мысль понял... Но, у меня немного структура другая... По нажатию на клавиши я не создаю новый поток, а просто работаю с флагами внутри созданного с момента запуска программы потока, а в нем постоянно опрашиваются эти флаги. В потоке у меня набор функционала под разные задачи, но они вызываются по разным флагам... Например читка файла... Реализована в потоке... я создал этот поток, в него всунул while, чтоб он постоянно работал... в конце while ставлю sleep(1), Вот если читать по 1 кб 1Гб файл и не поставить этот злополучный sleep(1), то проц будет перегружен. Ты понимаешь поток как однократное выполнение каких-либо функций и его закрытие, а я создаю поток (потоки) для их постоянной работы с момента запуска программы. 0

@sitesv 27 / 25 / 5 Регистрация: 22.04.2010 Сообщений: 772
	23.05.2010, 23:13 [ТС]
	нет, не отправка вызывает перегрузку, а считывание из файла и всякие операции между массивами. Отправляю по 1045 байт, на приемной стороне может быть 430+615, а как сделать так, чтобы на входе было только по 1045 байт? 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	23.05.2010, 23:14
	Три раза прочитал - ничо не понял 0

@fasked 5045 / 2624 / 241 Регистрация: 07.10.2009 Сообщений: 4,310 Записей в блоге: 5
	24.05.2010, 14:05
	Для управления потоками передачи данных (не теми потоками, которые создаешь ты) протокол TCP исопльзует специальный алгоритм, именуемый "скользящее окно". Суть его в том, что отправителю не обязательно дожидаться подтверждения приема со стороны получателя всех отправляемых данных. Протоколом TCP формируется подтверждение не для каждого успешно принятого пакета, а для некоторого количества отмечаемого порядковым номером ACK SN. Это количество может в процессе передачи меняться (отсюда и название "скользящее"). Алгоритм сам распределяет количество передаваемых данных, оптимизирует это количестве на основе анализа сети. То есть число переданных пакетов не обязательно сразу будет равно числу принятых пакетов. А ты по моему опять же пытаешься лезть на слишком низкий уровень. И опять же такой "простой" в работе сети не будет и заметен пользователю. Я никак не пойму с чего ты решил, что тормоза в передаче обусловлены именно самим процессом отправки/приема данных. К тому же если ты пользуешься не стандартными классами для чтения файлов, почему не воспользоваться уже разработанными кем-то классами сокетов. В Билдере насколько я могу помнить это TClientSocket и TServerSocket. 0

@sitesv 27 / 25 / 5 Регистрация: 22.04.2010 Сообщений: 772
	24.05.2010, 20:25 [ТС]
	В билдере есть эти классы, только в линуксе нет... Вот и приходится, чтобы наладить общение между виндой и линуксом, который установлен на микросхеме, работать на таком уровне с сокетами... Чтобы решить свою проблему с разбиением пришлось добавить функцию сегментации, которая собирает все данные приходящие от клиента в пакеты по 1045 байт... иначе никак не получилось... теперь все работает! А тормоза, я же уже писал выше, возникают не из-за передачи данных, а из-за моих слипов в потоках (TThread), которые давали возможность не перегружать процессор машины при непрерывном чтении большого файла... Для чтения из файла, передачи в другой поток этих данных и последующей передачи этого файла я убрал эти слипы, теперь все шуршит. Слипы вновь влючаются, когда программа находится в ждущем режиме или выполняются другие нересурсоемкие операции. Спасибо за ликбез по TCP) 0

@fasked
	24.05.2010, 21:00
	Не по теме: Однако, умение грамотно выражать свои мыслит это талант 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	24.05.2010, 23:44
	fasked, жирный +1. 0