LINUX.ORG.RU

История изменений

Исправление user_id_68054, (текущая версия) :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ само соделжимое уведомлений! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно запросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

операция «2» отличается от операции «3» — тем что во время операции «3» — происходит «быстрая» операция.

а во время операции «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в операции «2» сразы выдать клиенту нужные данные?.. зачем именно запрашивать КОЛИЧЕСТВО уведомление, а не само содержимое отведомлений?

ответ: потому что операция «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисекунду до начала разрыва).

операция «2» — не является надёжной, а операция «3» является надёжной.

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ само соделжимое уведомлений! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

операция «2» отличается от операции «3» — тем что во время операции «3» — происходит «быстрая» операция.

а во время операции «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в операции «2» сразы выдать клиенту нужные данные?.. зачем именно запрашивать КОЛИЧЕСТВО уведомление, а не само содержимое отведомлений?

ответ: потому что операция «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисекунду до начала разрыва).

операция «2» — не является надёжной, а операция «3» является надёжной.

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

операция «2» отличается от операции «3» — тем что во время операции «3» — происходит «быстрая» операция.

а во время операции «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в операции «2» сразы выдать клиенту нужные данные?.. зачем именно запрашивать КОЛИЧЕСТВО уведомление, а не само содержимое отведомлений?

ответ: потому что операция «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисекунду до начала разрыва).

операция «2» — не является надёжной, а операция «3» является надёжной.

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно запрашивать КОЛИЧЕСТВО уведомление, а не само содержимое отведомлений?

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомления, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с «зависанием» соединения)

3. клиент может запросить содержимое уведомления, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действиеу сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с «зависанием» соединения)

3. клиент может запросить содержимое уведомления, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действиеу сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest, с «зависанием» соединения)

3. клиент может запросить содержимое уведомления, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest, без «зависания» соединения)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действиеу сервера. передать серверу данные. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest)

3. клиент может запросить содержимое уведомления, заранее зная какое именно-количество умедомлений нужно зпросить. (через XMLHttpRequest)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действиеу сервера. передать серверу данные. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest)

3. клиент может запросить уведосления, заранее зная какое количество их есть. (через XMLHttpRequest)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest)

3. клиент может запросить уведосления, заранее зная какое количество их есть. (через XMLHttpRequest)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в действии «2» сразы выдать клиенту нужные данные?.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведомления! это важно!). (через XMLHttpRequest)

3. клиент может запросить уведосления, заранее зная какое количество их есть. (через XMLHttpRequest)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не может в действии «2» сразы выдать клиенту нужные данные.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исправление user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведосления). (через XMLHttpRequest)

3. клиент может запросить уведосления, заранее зная какое количество их есть. (через XMLHttpRequest)

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не может в действии «2» сразы выдать клиенту нужные данные.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).

Исходная версия user_id_68054, :

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие. (через XMLHttpRequest)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ сами уведосления).

3. клиент может запросить уведосления, заранее зная какое количество их есть.

действие «2» отличается от действия «3» — тем что во время действия «3» — происходит «быстрая» операция.

а во время действия «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не может в действии «2» сразы выдать клиенту нужные данные.. зачем именно вызывать КОЛИЧЕСТВО уведомление, а не сами отведомления

ответ: потому что действие «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисикунду до начала разрыва).