На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
  
    > Сетевая обработка
      Система состоит из сервера и клиента. Клиент подключаясь к серверу гонит ему поток на обработку.
      В данный момент передача данных синхронная.

      Но вот если после подключения сервер не успевает обрабатывать данные, то что произойдет
      1. Переполнится буфер сервера ?
      2. Клиент повиснет на send ?

      З.Ы. Меня в данные момент больше интерисует сторона клиента. Он не должен виснуть, иначе пойдет потеря данных.
        Цитата zss @
        Меня в данные момент больше интерисует сторона клиента. Он не должен виснуть, иначе пойдет потеря данных.

        А если перевести сокет клиента в неблокирующий режим ?

        Впрочем, потеря данных все равно возможна.
        Если в бассейн втекает больше чем вытекает, то рано
        или поздно польется через край..
          Цитата ЫукпШ @
          А если перевести сокет клиента в неблокирующий режим ?

          так прежде чем это делать, нужно понять где может быть проблема - на стороне сервера или клиента.


          Цитата ЫукпШ @
          Впрочем, потеря данных все равно возможна.
          Если в бассейн втекает больше чем вытекает, то рано
          или поздно польется через край..

          меня волнует не потеря со стороны сервера, а потеря со стороны клиенты. То есть если все-таки клиент будет заблокирован на send, то он потеряет данные, которые должен постоянно вычитывать из устройства и сохранять на винт, а уже только потом передавать по сети
            Цитата zss @
            Но вот если после подключения сервер не успевает обрабатывать данные, то что произойдет
            1. Переполнится буфер сервера ?
            2. Клиент повиснет на send ?
            Если сокет обычный, не блокирующий, то произойдет сначала 1, затем 2. Но на этом этапе данные не теряются, в смысле переполнение буфера на принимающей стороне - стандартная ситуация, которая просто сообщает передающей стророне о том, что нужно уменьшить скорость передачи данных.



            Цитата zss @
            То есть если все-таки клиент будет заблокирован на send, то он потеряет данные, которые должен постоянно вычитывать из устройства и сохранять на винт, а уже только потом передавать по сети
            Напрашивается вариант сделать два потока: один получает даные и надежно сохраняет из на диск, второй уже передает данные для обработки со своей скоростью.
            Ну либо делай неблокирующие сокеты и сам следи за временем выполнения сетевых операций, но это сложнее, да и наверно не нужно.
              Цитата albom @
              стандартная ситуация, которая просто сообщает передающей стророне о том, что нужно уменьшить скорость передачи данных.

              а как это проявится ?


              Цитата albom @
              Но на этом этапе данные не теряются, в смысле переполнение буфера на принимающей стороне

              это точно ?


              З.Ы. Еще вопрос - можно ли каким образом гарантировать транзакцию. Тоесть ли передано все - либо ничего ?

              Добавлено
              Цитата albom @
              Напрашивается вариант сделать два потока: один получает даные и надежно сохраняет из на диск, второй уже передает данные для обработки со своей скоростью.

              ну тогда нужен промежуточный буфер, который не хотелось заводить.
              Мне не критичны потери при передачи по сети. Данные можно и терять (важно лишь сохранение на винт).
              Из этого и хотелось реализовать как можно проще...
                Цитата zss @
                а как это проявится ?
                Передающая сторона уменьшит скорость передачи.
                С точки зрения приложения это всё прозрачно, всем этим будет заниматься ОС, сами данные будут накапливаться в буферах на передающей стороне, а когда они будут исчерпаны, то при очередной попытке передачи send будет заблокирован до тех пор, пока не будут переданы уже накопленные данные, и таким образом будут освобождены буферы.

                Цитата zss @
                это точно ?
                в tcp/ip - да

                Цитата zss @
                Еще вопрос - можно ли каким образом гарантировать транзакцию. Тоесть ли передано все - либо ничего ?
                Реализовать нужный протокол вручную.
                Ну или udp-дейтаграмы слать, если это допустимо.
                  Цитата albom @
                  то при очередной попытке передачи send будет заблокирован до тех пор, пока не будут переданы уже накопленные данные, и таким образом будут освобождены буферы.

                  этого я и боялся

                  Цитата albom @
                  Реализовать нужный протокол вручную.

                  а что это даст. Например, если данные потерялись, что tcp сам перезапросит их.
                  Тут главное чтоб не было так, что я получил часть, а при попытке получения оставшейся произошел обрыв, например.



                  Цитата albom @
                  Ну или udp-дейтаграмы слать, если это допустимо.

                  размер данных более 1500 - не получится.

                  З.Ы.
                  Цитата zss @
                  у тогда нужен промежуточный буфер, который не хотелось заводить.
                  Мне не критичны потери при передачи по сети. Данные можно и терять (важно лишь сохранение на винт).
                  Из этого и хотелось реализовать как можно проще...

                  А исходя из этого - можно упростить как-нибудь ?
                    Цитата zss @
                    а что это даст. Например, если данные потерялись, что tcp сам перезапросит их.
                    Тут главное чтоб не было так, что я получил часть, а при попытке получения оставшейся произошел обрыв, например.
                    Ну разделяешь свой неделимые сообщения неким разделителем, или перед каждым неделимым сообщением передаешь его размер. А на принимающей стороне пишешь читателя, который читает данные из сокета и передает данные дальше в твою программу только порциями, ну а порции он определять сможет или по разделителям или зная размер следующих данных.

                    Цитата zss @
                    А исходя из этого - можно упростить как-нибудь ?
                    Вот мне и кажется, что тут проще сделать две нити (или процесса). Один делает важную часть (получает данные и пишет их), а второй просто читает данные (да хоть прямо с диска и читает) и передает их в сеть. Вторая часть вообще получается простой, разве что тривиальную синхронизацию можно написать.
                      Цитата albom @
                      Вторая часть вообще получается простой, разве что тривиальную синхронизацию можно написать.

                      внутренний буфер меня смущает...


                      Цитата albom @
                      Ну разделяешь свой неделимые сообщения неким разделителем, или перед каждым неделимым сообщением передаешь его размер. А на принимающей стороне пишешь читателя, который читает данные из сокета и передает данные дальше в твою программу только порциями, ну а порции он определять сможет или по разделителям или зная размер следующих данных.

                      понятно
                        Цитата zss @
                        А исходя из этого - можно упростить как-нибудь ?

                        Можно смастерить обьект FiFo - контейнер для сообшений.
                        Обьект должен быть потокобезопасным.
                        Поток с большим приоритетом принимает данные и заполняет FiFo.
                        Другой рабочий поток извлекает Месаджы из FiFo и занимается
                        их отправкой.
                        Но независимо от того, где будут храниться данные аппаратуры
                        (на диске или в памяти) такая схема может спасти только
                        от пиковых перегрузок.
                        Сообщение отредактировано: ЫукпШ -
                        0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                        0 пользователей:


                        Рейтинг@Mail.ru
                        [ Script execution time: 0,0400 ]   [ 16 queries used ]   [ Generated: 28.04.24, 15:45 GMT ]