Протоколы без сохранения информации о состоянии считают лучше для использования по протоколам состояний?
Во-первых, 0 является совершенно допустимым «значением мусора».
Но это спорный вопрос, потому что вы на самом деле не конвертируете 4 байта в целое число & mdash; Вы извлекаете один байт, а затем конвертируете его в целое число. Вы должны были бы интерпретировать char* как int* (затем разыменовывать его), чтобы делать то, что вы говорите, что делаете, и тогда мы приходим к:
Неопределенное поведение
Такое манипулирование памятью имеет неопределенное поведение . Все может произойти, если вы попытаетесь сделать вид, что не int является int.
Процесс перевода абстрактной программы, которую вы описали с использованием слов C ++, в реальную практическую программу, понятную компьютеру, невероятно сложен . Компилятор не берет ваши строки по одной и просто наивно переписывает их в код, который одинаков, но на машинном языке. Он читает весь ваш исходный код, понимает, что вы хотите, чтобы программа, которую он описывает для вас, затем создает совершенно новую программу на совершенно другом, не связанном, отдельном языке, который дает тот же результат. Для того, чтобы сделать это быстро, нужны также ярлыки.
Когда вы пишете программу, поведение которой не определено, вы нарушаете этот процесс. Вы просто не можете предположить, что «мы должны получить целочисленное значение, равное 3 последним байтам первого байта [i] + a [1]». Вероятнее всего, это было правдой в 1970-х годах, но компьютеры действительно сложные, современные больше, чем старинные.
Короткая версия: не делай этого.
7 ответов
Насколько важный состояние к Вашему приложению? Вам нужен постоянный поток данных между различными машинами, или действительно ли более полезно иметь пакеты? Если Вы пишете приложение типа IP-телефонии затем, Вы, вероятно, собираетесь хотеть что-то довольно с сохранением информации, если можно сойти с рук не сохраняющий состояние, это, вероятно, будет более дешевым и легче сделать это тот путь. Выполнение вещей с сохранением информации обязательно более хрупко, потому что, если или конец соединения отбрасывается или само соединение спускается по Вам, рискуют потери данных, тогда как с соединением не сохраняющим состояние Вы более вероятны только должными быть ожидать некоторое время и попробовать еще раз.
Они действительно - различные инструменты для различных заданий, но, учитывая простоту и повсеместность технологий не сохраняющих состояние онлайн логично посмотреть в том направлении, когда у Вас есть опция.
Преимущества не сохраняющих состояние:
- Высокая масштабируемость (Вы, банка может отправить запрос к любому узлу, можно добавить узлы в любое время),
- Высокая доступность (если один узел перестал работать, нет никакого состояния, которое потеряно, просто снова посылает запрос другому узлу),
- Высокая скорость (как нет никакого состояния, результаты, является кэшируемой),
Я считал бы IT-область конкретной. Если Вы пишете моральный эквивалент ping, протокол без сохранения информации о состоянии является правильным выбором. С другой стороны, если Вы пишете, что VNC, с сохранением информации, является, конечно, способом пойти.
Что касается того, когда выбрать, который, существует две точки для мысли. Во-первых, в то время как выбором реализации является либо/либо, пространство задач является континуумом. Все задачи реального мира имеют, по крайней мере, небольшое состояние, вопрос состоит в том, насколько и издержки передачи его вокруг стоящего стычки отслеживания его в обоих концах. И во-вторых, Вы обычно имеете дело со стеком протоколов, ни одним протоколом; удостоверение, что все живет на правильном уровне, может упростить вещи чрезвычайно.
Протокол без сохранения информации о состоянии легче кластеризировать, так как состояние никогда не должно передаваться от 1 сервера до другого по последующим запросам.
Я не лично знаком со всеми вопросами проектирования с сохранением информации по сравнению с не сохраняющим состояние, но я действительно знаю, что NFSv4 с сохранением информации после ценности 15 лет предыдущих версий NFS, являющегося не сохраняющим состояние, таким образом, по-видимому, отсутствие гражданства стало значительным ограничением для разработчиков NFS.
Поиск с помощью Google нескольких минут показывает несколько статей и блогов, говорящих о NFSV4, с сохранением информации; это должно быть интересным чтением для некоторых включенных вопросов проектирования.
Другая хорошая вещь с протоколами без сохранения информации о состоянии состоит в том, что легче обработать ситуации с обработкой отказа сервера и/или ситуации с кластеризацией/выравниванием нагрузки.
С сохранением информации лучше. Затем Вы не должны отправлять состояние все время. Протокол затем становится более простым.