Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Ethereal писал(а): Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода ?check_buttons IF process_buttons THEN Я не то чтобы совсем против, но идея с отдельной явно выраженной многозадачностью у меня вызывает сомнения. Это же тоже отъест ресурсы и полагаться на волшебство в виде run_task/stop_task, не написав и продумав это самостоятельно... ну вот в соседнем треде показательный пример, как там человеку натурально впихнули совершенно ненужные ему дорогие программы. Многозадачность, наряду с ФортОС и IDE для Форта - из разряда несбыточных мечт, которые обязательно должны все исправить, вот только... Пример со звуком скорее тянет на тщательную проработку задачи в машинном коде. По идее, это как раз противоположно тому, чтобы не глядя отдать решение на откуп "бренду". Ethereal писал(а): Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся. Тут надо тщательно обдумать. Мы говорим о многозадачности или многопоточности? И опять же, USER-переменных, или просто локальных переменных потока?
[quote="Ethereal"]Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода ?check_buttons IF process_buttons THEN[/quote] Я не то чтобы совсем против, но идея с отдельной явно выраженной многозадачностью у меня вызывает сомнения. Это же тоже отъест ресурсы и полагаться на волшебство в виде run_task/stop_task, не написав и продумав это самостоятельно... ну вот в соседнем треде показательный пример, как там человеку натурально впихнули совершенно ненужные ему дорогие программы. Многозадачность, наряду с ФортОС и IDE для Форта - из разряда несбыточных мечт, которые обязательно должны все исправить, вот только...
Пример со звуком скорее тянет на тщательную проработку задачи в машинном коде. По идее, это как раз противоположно тому, чтобы не глядя отдать решение на откуп "бренду".
[quote="Ethereal"]Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.[/quote] Тут надо тщательно обдумать. Мы говорим о многозадачности или многопоточности? И опять же, USER-переменных, или просто локальных переменных потока?
|
|
|
|
Добавлено: Пн янв 15, 2018 01:09 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Hishnik писал(а): Опять же, возможен "прямой" код вида BEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN
Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода ?check_buttons IF process_buttons THEN Hishnik писал(а): Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.
[quote="Hishnik"]Опять же, возможен "прямой" код вида BEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN [/quote]Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода ?check_buttons IF process_buttons THEN[quote="Hishnik"]Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям[/quote]Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.
|
|
|
|
Добавлено: Пн янв 15, 2018 00:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Ethereal писал(а): Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить. А зачем же это рассматривать как что-то отдельное? В процессе выбора архитектуры приняли решение о назначении прерываний и наличии непрерываемых фрагментов кода. Опять же, возможен "прямой" код вида BEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям, а основной цикл может быть и просто пустым. Однако это сильно зависит от МК. Ethereal писал(а): Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться. TCP/IP действительно кандидат на выделение задачи, но опять же - в зависимости от общей архитектуры системы и программного проекта. Слабые МК банально просядут при попытке выделить им отдельный менеджер задач со своими временными ресурсами. Кроме того, без MMU многозадачность представляет собой нечто зыбкое в плане надежности. А уж если TCP принимает данные, нужные спутнику, то необходимо обеспечить совместный доступ к этим данным из двух задач. И даже с задекларированной многозадачностью (в виде какой-то библиотеки), но без настоящего MMU источник потенциальных проблем все равно остается. По впечатлению - искусственные навороты не спасают(чудес не бывает и процессор один). Прерывания спасают слабо (процессор все равно один). Вот аппаратное распараллеливание уже очень хорошо и на корню решает проблему (две задачи так две задачи - значит будет два процессорных ядра). Горыныч оказался совсем удобен - там динамическое распределение временных слотов с нулевым штрафом на переход.
[quote="Ethereal"]Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.[/quote] А зачем же это рассматривать как что-то отдельное? В процессе выбора архитектуры приняли решение о назначении прерываний и наличии непрерываемых фрагментов кода. Опять же, возможен "прямой" код вида
BEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN
Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям, а основной цикл может быть и просто пустым. Однако это сильно зависит от МК.
[quote="Ethereal"]Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.[/quote] TCP/IP действительно кандидат на выделение задачи, но опять же - в зависимости от общей архитектуры системы и программного проекта. Слабые МК банально просядут при попытке выделить им отдельный менеджер задач со своими временными ресурсами. Кроме того, без MMU многозадачность представляет собой нечто зыбкое в плане надежности. А уж если TCP принимает данные, нужные спутнику, то необходимо обеспечить совместный доступ к этим данным из двух задач. И даже с задекларированной многозадачностью (в виде какой-то библиотеки), но без настоящего MMU источник потенциальных проблем все равно остается.
По впечатлению - искусственные навороты не спасают(чудес не бывает и процессор один). Прерывания спасают слабо (процессор все равно один). Вот аппаратное распараллеливание уже очень хорошо и на корню решает проблему (две задачи так две задачи - значит будет два процессорных ядра). Горыныч оказался совсем удобен - там динамическое распределение временных слотов с нулевым штрафом на переход.
|
|
|
|
Добавлено: Пн янв 15, 2018 00:10 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
mOleg писал(а): ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать). Смотря где. Если датчик в контуре автоматизированного управления, то отрисовки может и вообще не быть. Если же это прибор, то нет смысла измерять и ничего не показывать (включая "показ" по внешнему интерфейсу, т.е. отправку данных). Поэтому двух задач тут нет, тут задача одна - организация измерений, которая без одного из компонентов просто перестанет существовать. Опять же, где именно отрисовка запаздывает? В семисегментном индикаторе? В LCD с SPI? В UART? Большинство устройств отображения не имеет сигналов готовности или же имеют такие режимы, которые без этих сигналов прекрасно обходятся.
[quote="mOleg"]ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать).[/quote] Смотря где. Если датчик в контуре автоматизированного управления, то отрисовки может и вообще не быть. Если же это прибор, то нет смысла измерять и ничего не показывать (включая "показ" по внешнему интерфейсу, т.е. отправку данных). Поэтому двух задач тут нет, тут задача одна - организация измерений, которая без одного из компонентов просто перестанет существовать.
Опять же, где именно отрисовка запаздывает? В семисегментном индикаторе? В LCD с SPI? В UART? Большинство устройств отображения не имеет сигналов готовности или же имеют такие режимы, которые без этих сигналов прекрасно обходятся.
|
|
|
|
Добавлено: Вс янв 14, 2018 23:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Hishnik писал(а): Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить. Hishnik писал(а): Многозадачность тут сильно смахивает на "магию бренда" Решал я задачу воспроизведения WAV-файла с SD-флешки на 20-мегагерцовом PIC18. Так вот со стандартными WAV-файлами с частотой оцифровки 44100 Гц вообще быстродействия не зватило никак. Но поскольку в WAV-ах была не музыка, а вибрации сложной формы, то вопрос решился допустимым занижением частоты оцифровки. Но все равно при вопроизведении оперативная задача жрала львиную долю процессорного времени, а фоновая продвигалась короткими рывками в промежутках. Во время очередного рывка исполнялся лишь небольшой кусочек главного цикла фоновой задачи. Вот пример программы, которую без двузадачности было не написать никак. Такие задачи бывают. Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.
[quote="Hishnik"]Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие.[/quote]Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.[quote="Hishnik"]Многозадачность тут сильно смахивает на "магию бренда"[/quote]Решал я задачу воспроизведения WAV-файла с SD-флешки на 20-мегагерцовом PIC18. Так вот со стандартными WAV-файлами с частотой оцифровки 44100 Гц вообще быстродействия не зватило никак. Но поскольку в WAV-ах была не музыка, а вибрации сложной формы, то вопрос решился допустимым занижением частоты оцифровки. Но все равно при вопроизведении оперативная задача жрала львиную долю процессорного времени, а фоновая продвигалась короткими рывками в промежутках. Во время очередного рывка исполнялся лишь небольшой кусочек главного цикла фоновой задачи. Вот пример программы, которую без двузадачности было не написать никак. Такие задачи бывают. Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.
|
|
|
|
Добавлено: Вс янв 14, 2018 22:10 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Hishnik писал(а): Прочитать датчики и выполнить действия - это по сути одна задача, ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать). Но, конечно, это не означает, что нельзя использовать другое решение. Вопрос лишь в том как проще добиться необходимого результата. Я не вижу проблемы с пользовательскими переменными. Они, как и многозадачность, прекрасно уходят в библиотеку, и подключаются при необходимости.
[quote="Hishnik"]Прочитать датчики и выполнить действия - это по сути одна задача,[/quote] ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать). Но, конечно, это не означает, что нельзя использовать другое решение. Вопрос лишь в том как проще добиться необходимого результата. Я не вижу проблемы с пользовательскими переменными. Они, как и многозадачность, прекрасно уходят в библиотеку, и подключаются при необходимости.
|
|
|
|
Добавлено: Вс янв 14, 2018 21:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Если число задач известно заранее, то где же здесь "много-"? Прочитать датчики и выполнить действия - это по сути одна задача, хотя бы потому что данные как раз общие, а не раздельные, как при многозадачной работе. Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. А если в программе на МК отвалится датчик, то остальные компоненты программы станут бесполезны. USER-переменные в данном случае успешно заменяются на обычные локальные переменные процедур. Многозадачность тут сильно смахивает на "магию бренда", когда в проект необоснованно добавляются какие-то подходы, которые у всех на слуху, но в конкретном проекте ну совершенно ни к чему.
Если число задач известно заранее, то где же здесь "много-"? Прочитать датчики и выполнить действия - это по сути одна задача, хотя бы потому что данные как раз общие, а не раздельные, как при многозадачной работе. Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. А если в программе на МК отвалится датчик, то остальные компоненты программы станут бесполезны. USER-переменные в данном случае успешно заменяются на обычные локальные переменные процедур. Многозадачность тут сильно смахивает на "магию бренда", когда в проект необоснованно добавляются какие-то подходы, которые у всех на слуху, но в конкретном проекте ну совершенно ни к чему.
|
|
|
|
Добавлено: Вс янв 14, 2018 17:13 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Простейшая МК-система с семисегментным индикатором и кнопками уже требует двузадачности. Обычно я делаю динамическую индикацию в обработчике прерывания по таймеру и опрос кнопок и реакцию на их нажатия главным циклом. Но это на ассемблере. И вообще МК-задача типично разбивается на две - делать то, что должен делать фоновой задачей и реагировать на действия пользователя оперативно. На форте сделал бы корпоративную двузадачность. Плата за наличие такой возможности ведь минимальна - ну слова STATE BASE и еще несколько штук должны быть не value, а именно переменными плюс наличие слово USER опционально. На мой взгляд вообще не плата, ибо само наличие VALUE тоже должно быть опционально. Ну лишняя это сущность в минимальном ядре.
Простейшая МК-система с семисегментным индикатором и кнопками уже требует двузадачности. Обычно я делаю динамическую индикацию в обработчике прерывания по таймеру и опрос кнопок и реакцию на их нажатия главным циклом. Но это на ассемблере. И вообще МК-задача типично разбивается на две - делать то, что должен делать фоновой задачей и реагировать на действия пользователя оперативно. На форте сделал бы корпоративную двузадачность. Плата за наличие такой возможности ведь минимальна - ну слова STATE BASE и еще несколько штук должны быть не value, а именно переменными плюс наличие слово USER опционально. На мой взгляд вообще не плата, ибо само наличие VALUE тоже должно быть опционально. Ну лишняя это сущность в минимальном ядре.
|
|
|
|
Добавлено: Вс янв 14, 2018 04:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
один поток снимает показания с датчика (по одному потоку на датчик) в другом крутится оболочка, занимающаяся отрисовкой и сохранением данных.
один поток снимает показания с датчика (по одному потоку на датчик) в другом крутится оболочка, занимающаяся отрисовкой и сохранением данных.
|
|
|
|
Добавлено: Ср янв 10, 2018 15:47 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Цитата: У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные. Так и знал, что мы говорим о разном немножко. Однако ж USER-переменные актуальны. В винде по крайне мере. Цитата: А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка. Не знаю как раньше, но сейчас на форте иногда балуются с корпоративной многозаачностью. Вроде бы интересно, но где применяется никто не видел. В СПФ-е либа есть где-то. Лучше уж писать "тупые" либы по работе с сетью, файлами, поиск, разбор. Больше шансов, что пригодится.
[quote]У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные. [/quote]
Так и знал, что мы говорим о разном немножко. Однако ж USER-переменные актуальны. В винде по крайне мере.
[quote]А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка.[/quote]
Не знаю как раньше, но сейчас на форте иногда балуются с корпоративной многозаачностью. Вроде бы интересно, но где применяется никто не видел. В СПФ-е либа есть где-то. Лучше уж писать "тупые" либы по работе с сетью, файлами, поиск, разбор. Больше шансов, что пригодится.
|
|
|
|
Добавлено: Ср янв 10, 2018 00:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Victor__v писал(а): Не, ну это как? я лично не знаю способа запустить потоки без средств ОС. Если Вам известен способ запустить поток минуя ОС, то я весь во внимании. У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные. А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка.
[quote="Victor__v"]Не, ну это как? я лично не знаю способа запустить потоки без средств ОС. Если Вам известен способ запустить поток минуя ОС, то я весь во внимании.[/quote] У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные. А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка.
|
|
|
|
Добавлено: Ср янв 10, 2018 00:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Цитата: Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется Не, ну это как? я лично не знаю способа запустить потоки без средств ОС. Если Вам известен способ запустить поток минуя ОС, то я весь во внимании. И кто переизобретает управление потоками? Кто этот негодяй? На современных операционках это дело лишние. Да и форте потоки запускаются средствами ОС.
[quote]Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется[/quote] Не, ну это как? я лично не знаю способа запустить потоки без средств ОС. Если Вам известен способ запустить поток минуя ОС, то я весь во внимании. И кто переизобретает управление потоками? Кто этот негодяй? На современных операционках это дело лишние.
Да и форте потоки запускаются средствами ОС.
|
|
|
|
Добавлено: Вт янв 09, 2018 20:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Victor__v писал(а): Однопоточные серверные приложения Однопоточный Форт <> однопоточное серверное приложения. Серверные приложения ведь как-то существуют в многопоточных вариантах и без Форта. Victor__v писал(а): Быть сервером. Тут многопоточность по-любому. Нет, это слишком общее. Есть понятие "сценарии применения". Что конкретно надо будет написать на таком Форте? Если просто be_server, то это опять же не вариант. Это можно вызвать просто другое серверное приложение через ShellExecute - вон как Шабронов нас тут всех "просветил". С очень большой вероятностью может оказаться, что переключение форт-потоков никакой особой проблемы и не решает. Victor__v писал(а): В чём тут форт имеет приемущество? Компиляция во время выполнения. Возможность на ходу поправить скритпы-исходники и сбросить и перезапиустить приложение. Короче, сочетание двух ипостасей форт-системы. Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется. Сервер устойчив к множественным запросам, точно так же, как и другие серверные приложения, использующие эти механизмы ОС.
[quote="Victor__v"]Однопоточные серверные приложения [/quote] Однопоточный Форт <> однопоточное серверное приложения. Серверные приложения ведь как-то существуют в многопоточных вариантах и без Форта. [quote="Victor__v"]Быть сервером. Тут многопоточность по-любому.[/quote] Нет, это слишком общее. Есть понятие "сценарии применения". Что конкретно надо будет написать на таком Форте? Если просто be_server, то это опять же не вариант. Это можно вызвать просто другое серверное приложение через ShellExecute - вон как Шабронов нас тут всех "просветил". С очень большой вероятностью может оказаться, что переключение форт-потоков никакой особой проблемы и не решает. [quote="Victor__v"]В чём тут форт имеет приемущество? Компиляция во время выполнения. Возможность на ходу поправить скритпы-исходники и сбросить и перезапиустить приложение. Короче, сочетание двух ипостасей форт-системы.[/quote] Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется. Сервер устойчив к множественным запросам, точно так же, как и другие серверные приложения, использующие эти механизмы ОС.
|
|
|
|
Добавлено: Вт янв 09, 2018 20:06 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
Victor__v писал(а): Ежели сервер однопоточный то и DDOS не нужен Ой, точно)
[quote="Victor__v"]Ежели сервер однопоточный то и DDOS не нужен :)[/quote]Ой, точно)
|
|
|
|
Добавлено: Вт янв 09, 2018 19:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: о преимуществах и недостатках существующих стандартов |
|
|
_KROL писал(а): Hishnik писал(а): ... В действительности, как можно использовать однопоточность в всемирной паутине? Это может и выгодно для некоторых серверов, которые мало общаются с каждым клиентом, но как тогда защитится от DDOS атак? Victor__v писал(а): ... Редко встречается в нашем мире и однозадачность Например в Обероне, который тоже можно использовать как сервер. Но такой подход, как я понял, неплох для небольшой локальной сети, а не WWW. Ежели сервер однопоточный то и DDOS не нужен
[quote="_KROL"][quote="Hishnik"]...[/quote]В действительности, как можно использовать однопоточность в всемирной паутине? Это может и выгодно для некоторых серверов, которые мало общаются с каждым клиентом, но как тогда защитится от DDOS атак? [quote="Victor__v"]...[/quote]Редко встречается в нашем мире и однозадачность :D Например в Обероне, который тоже можно использовать как сервер. Но такой подход, как я понял, неплох для небольшой локальной сети, а не WWW.[/quote]
Ежели сервер однопоточный то и DDOS не нужен :)
|
|
|
|
Добавлено: Вт янв 09, 2018 19:17 |
|
|
|
|