тем что сервер ничего про это же не знает

Если он на ноде, то мб и да

Кто это сказал?

ну расскажи как)

Ну хлопнул клиент сокет, чтож теперь

сервер знает про дроп соединения только если это persistent connection

Конечная сторона 100% узнает что связь порвалась

Конечная сторона 100% узнает что связь порвалась

как?

вот есть tcp, как он поймет?

да никак, Лёша прав

кто этим займется? маршрутизатор?

сервер не знает

что клиент убил соединение

вот есть tcp, как он поймет?

Выдержка из вики Завершение соединения Завершение соединения можно рассмотреть в три этапа: Посылка серверу от клиента флага FIN на завершение соединения. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

Это не удп, которому пофигу на статус доставки

Выдержка из вики Завершение соединения Завершение соединения можно рассмотреть в три этапа: Посылка серверу от клиента флага FIN на завершение соединения. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

вооот, это надо отправляет еще в догонку

> Посылка серверу от клиента флага FIN если этого не происходит, сервер не знает про завершение соединения

вооот, это надо отправляет еще в догонку

Это сама ОС делает при закрытии сокета

Так-то еще таймауты есть

Боже, вы издеваетесь?

Так-то еще таймауты есть

Не надо ломать их мир

Возьмите да сниффером посмотрите

wireshark в помощь

таймауты есть на стороне клиента на ответ от сервера, а не на стороне сервера на запрос от клиента

таймауты есть на стороне клиента на ответ от сервера, а не на стороне сервера на запрос от клиента

Если коннект установился и потом клиент его рвет - серв узнает

В tcp вообще-то на все есть таймаут

А HTTP поверх него работает

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

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

На изи

Это реально же

покажи мне хоть один сервак который так работает

Помогу еще разок

https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#.D0.A1.D0.BE.D1.81.D1.82.D0.BE.D1.8F.D0.BD.D0.B8.D1.8F_.D1.81.D0.B5.D0.B0.D0.BD.D1.81.D0.B0_TCP

Это все уже есть в тср

Помогу еще разок

блин ты писал хоть раз сервер?

блин ты писал хоть раз сервер?

netty сойдет?

покажи мне хоть один сервак который так работает

Хочешь сказать, если я буду файл в 20 гигов качать и отменю в самом начале, мне все 20 гигов все равно придут?

блин ты писал хоть раз сервер?

асинхронщина на перле еще была в свое время

покажи мне хоть один сервак который так работает

кажись FastCGI так работает

Хочешь сказать, если я буду файл в 20 гигов качать и отменю в самом начале, мне все 20 гигов все равно придут?

АХАХАХАХ

Хочешь сказать, если я буду файл в 20 гигов качать и отменю в самом начале, мне все 20 гигов все равно придут?

нет, ты отправишь серверу запрос на закрытие соединения

То, что конкретно ВАШ сервер это не осиляет - не означает что другие так не могут

нет, ты отправишь серверу запрос на закрытие соединения

Воооот

камон, че херню несете. вот пришел http запрос, ты получил реквест и пошел в базу. как ты отменишь запрос? как ты вообще это поймешь?

и я не про статику сейчас говорю

камон, че херню несете. вот пришел http запрос, ты получил реквест и пошел в базу. как ты отменишь запрос? как ты вообще это поймешь?

Тут никак, но как минимум ответ отправлять не будешь

камон, че херню несете. вот пришел http запрос, ты получил реквест и пошел в базу. как ты отменишь запрос? как ты вообще это поймешь?

ты - никак, какой-нибудь nginx сверху может кильнуть твой php процесс, т.к. знает, что он уже работает вхолостую

ты - никак, какой-нибудь nginx сверху может кильнуть твой php процесс, т.к. знает, что он уже работает вхолостую

Поток хлопнуть там

а может и не кильнуть

А может метеорит на сервер упасть, давайте без крайностей

зависит от конкретного кейса, а вообще в той же ноде есть событие abort, которое как раз возникает когда клиент вызывает .abort у xhr

А может метеорит на сервер упасть, давайте без крайностей

так вы сами на уровне предположений говорите

а может и не кильнуть

Ага, поэтому давайте просто игнорить ответ

Ага, поэтому давайте просто игнорить ответ

чем это хуже?

чем это хуже?

Ну да, трафик и скорость соединения же не ограничены

чем это хуже?

Завчем дергать сеть ради бесполезных данных?

И батарея

И батарея

А потом удивляемся, "А что это мобила за полдня садится"

так так так

ребят

стопэ

ну то есть три этапа на закрытие это не бесполезно?

вот линк на w3.org, на часть про аборт

https://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/#the-abort-method

ну то есть три этапа на закрытие это не бесполезно?

Какие три?

мы начали с этого, этим и закончим

по линке не написано ничего про закрытие соединения

Какие три?

Вызвать метод abort так сложно, что это как три этапа

Выдержка из вики Завершение соединения Завершение соединения можно рассмотреть в три этапа: Посылка серверу от клиента флага FIN на завершение соединения. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

сам то читаешь что кидаешь? я тут три запроса насчитал

просто удаляются таски из очереди

сам то читаешь что кидаешь? я тут три запроса насчитал

Блэт

ну то есть три этапа на закрытие это не бесполезно?

так оно один фиг будет закрываться, либо при abort(), либо после завершения обмена данными

ЭТО ТСР!

КАРЛ!

и чо

...

сам то читаешь что кидаешь? я тут три запроса насчитал

Не запроса, а сообщений tcp

Разницу понимаем?

Не запроса, а сообщений tcp

какое отличие?

какое отличие?

Отличие между ТСР и НТТР?

какое отличие?

RTFM

и чо

то, что при abort() нету никаких накладных расходов по сравнению с игнорированием данных

Советую понять, как работает TCP, прежде чем спорить

по линке не написано ничего про закрытие соединения

я так понял вот The user agent should cancel any network activity for which the object is responsible

Советую понять, как работает TCP, прежде чем спорить

А про OSI если копнуть?

Разные уровни протоколов)

А про OSI если копнуть?

Еще лучше

я так понял вот The user agent should cancel any network activity for which the object is responsible

ага, там написано про удаление тасков на запросы

из очереди

Но проще просто формошлепить

но ничего про дроп самого соединения

так что даже если вы хренанете abort, он отрабатывает только на стороне клиента

ага, там написано про удаление тасков на запросы

это в 3-м рункте уже про таски

Вся демагогия бредовая

Вон wireshark в руки и вперед

мне кажется "The user agent should cancel any network activity for which the object is responsible." не подразумевает закрытие соединения

хотя, Денис прав

надо просто открыть wireshark

и поставить точку одним скрином ?

Прям вангую, что аборт закроет сокет на клиенте

¯\_(ツ)_/¯