м |
|
| Строка 1: |
Строка 1: |
| - | == Какие примитивы сокетов Беркли являются блокирующими? == | + | == From Ebaums Inc to MurkLoar. == |
| - | * [-] socket
| + | We at EbaumsWorld consider you as disgrace of human race. |
| - | * [-] receive
| + | Your faggotry level exceeded any imaginable levels, and therefore we have to inform you that your pitiful resourse should be annihilated. |
| - | * [+] connect
| + | Dig yourself a grave - you will need it. |
| - | * [-] listen
| + | |
| - | * [+] accept
| + | |
| - | | + | |
| - | == Используется управляемая часами схема генерации порядковых номеров. Частота тиканья часов 10 Гц, время жизни пакета 10 сек, счетчик часов 10-разрядный. Как часто (раз/час) должна производиться ресинхронизация при отправке 5 пакетов в секунду? ==
| + | |
| - | * (-) 12
| + | |
| - | * (-) 30
| + | |
| - | * (+) 60
| + | |
| - | * (-) 300
| + | |
| - | | + | |
| - | == Используется управляемая часами схема генерации порядковых номеров. Частота тиканья часов 10 Гц, время жизни пакета 10 сек, счетчик часов 10-разрядный. С какой скоростью (раз/сек) должны отправляться пакеты, чтобы избежать ресинхронизации? ==
| + | |
| - | * (-) 5
| + | |
| - | * (+) 10
| + | |
| - | * (-) 15
| + | |
| - | * (-) 20
| + | |
| - | | + | |
| - | == Протокол какого уровня должен обеспечивать восстановление после сбоя транспортного протокола? ==
| + | |
| - | * (-) Сетевого
| + | |
| - | * (-) Транспортного
| + | |
| - | * (+) Прикладного
| + | |
| - | * (-) Физического
| + | |
| - | | + | |
| - | == Для чего может применяться нисходящее мультиплексирование при взаимодействии транспортного и сетевого уровня? ==
| + | |
| - | * Для использования нескольких сетевых соединений с ограниченной пропускной способностью
| + | |
| - | * [+] Для использования одного канала несколькими процессами
| + | |
| - | * Для увеличения пропускной способности канала
| + | |
| - | | + | |
| - | (Нисходящее мультиплексирование - отображение нескольких транспортных соединений в одно сетевое)
| + | |
| - | | + | |
| - | == Каковы возможные причины возникновения перегрузок? ==
| + | |
| - | * [+] не достаточная емкость получателя
| + | |
| - | * [+] не достаточная надежность сети
| + | |
| - | * [-] не достаточная емкость сети
| + | |
| - | * [-] не достаточная чистота канала передачи
| + | |
| - | | + | |
| - | == TPDU - это: ==
| + | |
| - | * (+) Сообщение, с которым работает транспортный протокол
| + | |
| - | * (-) Сущность, реализующая функции транспортного протокола
| + | |
| - | * (-) Прикладная программа, работающая с сетью
| + | |
| - | * (-) Программа, эмулирующая работу транспортного протокола
| + | |
| - | | + | |
| - | == Как можно "обойти" "проблему двух армий"? ==
| + | |
| - | * (-) При помощи шифрования передаваемых данных
| + | |
| - | * (+) При помощи введения таймаута
| + | |
| - | * (-) При помощи введения уникального идентификатора TPDU
| + | |
| - | * (-) При помощи записи в TPDU временнОй метки
| + | |
| - | | + | |
| - | == Почему необходимо подтверждение получения TPDU, если на сетевом уровне уже обеспечивается подтверждение получения сетевых пакетов? ==
| + | |
| - | * (-) Для исправления возможных ошибок сетевого уровня
| + | |
| - | * (-) Для обеспечения универсальности протокола
| + | |
| - | * (+) TPDU может быть не принят получателем, даже если он был успешно доставлен
| + | |
| - | * (-) Так исторически сложилось, т.к. протоколы разрабатывались независимо
| + | |
| - | | + | |
| - | == Какова последовательность выполнения примитивов сокетов Беркли при установлении соединения со стороны клиента? ==
| + | |
| - | * ( ) socket - bind - connect
| + | |
| - | * (+) socket - connect
| + | |
| - | * ( ) bind - socket - receive
| + | |
| - | * ( ) socket - bind - listen - accept
| + | |
| - | * ( ) connect - socket - accept
| + | |
| - | Так в редклассе. Garret
| + | |
| - | | + | |
| - | == Основное отличие транспортного уровня от сетевого в том, что: ==
| + | |
| - | * [-] Сетевой уровень не устанавливает соединение
| + | |
| - | * [-] Транспортный уровень не занимается вопросами адресации
| + | |
| - | * [+] Сетевой уровень моделирует сервисы реальной сети
| + | |
| - | * [-] Транспортный уровень всегда гарантирует надежную передачу данных
| + | |
| - | | + | |
| - | (Это явно неправильно. К примеру, UDP не гарантирует надёжную передачу. \\Ramiz)
| + | |
| - | | + | |
| - | (Транспортный сервис аналогичен сервису сетевого уровня. Однако между ними существует одно различие - сетевой сервис по природе своей ненадежен. Задача транспортного сервиса как раз обеспечить надежную доставку сообщений. Два процесса, соединенные между собой, ничего не должны знать о том, как физически они соединены. Один помещает данные на вход транспортного уровня, другой получает их. Задача транспортного уровня скрыть и от получателя и от отправителя все детали передачи, исправления ошибок и т.п.
| + | |
| - | | + | |
| - | Остальные еще меньше подходят \\LLIyPuK)
| + | |
| - | | + | |
| - | (А если так? — [[Участник:Esyr01|eSyr]] 09:05, 23 мая 2007 (MSD))
| + | |
| - | | + | |
| - | == Какое мультиплексирование допускается при взаимодействии транспортного и сетевого уровня? ==
| + | |
| - | * (-) Мультиплексирование недопустимо
| + | |
| - | * (-) Тольно нисходящее
| + | |
| - | * (-) Только восходящее
| + | |
| - | * (+) Восходящее и нисходящее
| + | |
| - | | + | |
| - | == Чем идентифицируется соединение в TCP? ==
| + | |
| - | * (-) виртуальным соединением
| + | |
| - | * (+) парой сокетов
| + | |
| - | * (-) парой портов
| + | |
| - | * (-) связкой порт-сокет
| + | |
| - | | + | |
| - | == В чем основная идея принципа управления буферизацией? ==
| + | |
| - | * ( ) избегать переполнения буфера
| + | |
| - | * (+) избегать излишнего копирования пакетов
| + | |
| - | * ( ) динамически устанавливать размер буфера равным максимальному размеру пакета
| + | |
| - | * ( ) динамически устанавливать размер буфера равным размеру окна
| + | |
| - | | + | |
| - | == Какой принцип лежит в основе борьбы протокола TCP с перегрузками? ==
| + | |
| - | * (+) Принцип сохранения количества пакетов
| + | |
| - | * (-) Принцип сохранения времени отклика узла
| + | |
| - | * (-) Принцип сохранения качества связи
| + | |
| - | * (-) Принцип сохранения размера окна
| + | |
| - | | + | |
| - | == Какие виды соединений поддерживает TCP? ==
| + | |
| - | * (+) соединение точка-точка
| + | |
| - | * (-) соединение одного ко многим
| + | |
| - | * (-) соединение сногих к одному
| + | |
| - | * (-) соединение многие к многим
| + | |
| - | | + | |
| - | == Какие поля входят в структуру TCP-заголовка? ==
| + | |
| - | * [+] Source Port
| + | |
| - | * [+] Destination Port
| + | |
| - | * [+] Options
| + | |
| - | * [+] Window Size
| + | |
| - | * [+] Checksum
| + | |
| - | * [-] Length
| + | |
| - | * [+] Sequence Number
| + | |
| - | * [+] Urgent Pointer
| + | |
| - | | + | |
| - | == Выберите задачи, решаемые на транспортном уровне: ==
| + | |
| - | * [-] Маршрутизация
| + | |
| - | * [+] Управление соединением
| + | |
| - | * [+] Адресация
| + | |
| - | * [ ] Надежная передача данных по физическому каналу
| + | |
| - | * [+] Предоставление прикладным программам стандартного сервиса
| + | |
| - | | + | |
| - | == Чем отличается протокол TCP от протокола сетевого уровня? ==
| + | |
| - | * [+] Протоколы сетвого уровня не используют порты
| + | |
| - | * [+] Протокол TCP обеспечивает передачу байтового потока
| + | |
| - | * [-] Протоколы сетевого уровня не занимается управлением потока
| + | |
| - | * [+] Протокол TCP гарантирует надежную передачу данных
| + | |
| - | | + | |
| - | == Какие таймеры использует протокол TCP? ==
| + | |
| - | * [-] таймер передачи
| + | |
| - | * [+] таймер повторной передачи
| + | |
| - | * [+] таймер постоянства
| + | |
| - | * [-] таймер устойчивости
| + | |
| - | * [+] таймер функционирования
| + | |
| - | | + | |
| - | == Что может служить причиной перегрузки ... ==
| + | |
| - | * [+] Низкая пропускная способность канала
| + | |
| - | * [+] Низкая производительность получателя
| + | |
| - | | + | |
| - | == Какие основные проблемы решает протокол TCP? ==
| + | |
| - | * [+] восстанавливает порядок сегментов
| + | |
| - | * [+] убирает дубликаты сегментов
| + | |
| - | * [+] обеспечивает надежную передачу данных
| + | |
| - | * [ ] обеспечивает маршрутизацию
| + | |
| - | * [+] устанавливает и разрывает соединения надежно
| + | |
| - | * [+] управляет перегрузками
| + | |
| - | | + | |
| - | (TCP - надёжный транспортный протокол. Он обеспечивает надёжную передачу данных)
| + | |
| - | | + | |
| - | == Какие поля входят в структуру UDP-заголовка? ==
| + | |
| - | * [+] Source port
| + | |
| - | * [+] Destination port
| + | |
| - | * [-] Option
| + | |
| - | * [-] Window size
| + | |
| - | * [+] Checksum
| + | |
| - | * [+] Length
| + | |
| - | * [-] Sequence number
| + | |
| - | * [-] Urgent pointer
| + | |
| - | | + | |
| - | == Решение проблемы <глупого окна>, предложенное Кларком, заключается в следующем: ==
| + | |
| - | * [+] получатель должен ждать, когда в буфере освободиться размер, равный максимальной длине сегмента, объявленной при установке соединения
| + | |
| - | * [-] получатель должен ждать, когда в буфере освободится размер, равный длине сегмента, посланного последним
| + | |
| - | * [+] получатель должен ждать, когда в буфере освободиться половина(?) буфера
| + | |
| - | * [+] отправитель должен слать данные только большими сегментами
| + | |
| - | * [-] отправитель должен слать данные только ... сегментами
| + | |
