Octane,
я убедился, что описанная Вами практика не очень хороша, потому что периодическая проверка содержимого поля с каким-то интервалом (каким?) начинает ощутимо грузить процессор, а в IE при этом курсор начинает лихорадочно мигать.
demoniqus,
на практике стараются не убить уже отправленные запросы, а не допустить отправку пачки запросов в заданном промежутке времени. Например, при построении механизма "live search" когда пользователь последовательно нажимает буквы поискового слова нужно по keyup запускать таймер времени на 500-700 ms. Если в течение этого времени опять сработало событие keyup, то перезапускать таймер снова. Как только пользователь прекратит набор текста, т.е. в течение 700 ms не нажмет ни одной клавиши, то на сервер будет отправлен один запрос (он же последний).
При этом в некоторых системах всё же возможны ситуации отсылки дубликатов запросов типа
http://mysite.ru?x=aaaaaaa и снова
http://mysite.ru?x=aaaaaaa. Для этого лично я опробовал механизм стека запросов. Как это работает: перед отправкой запроса его параметры (или вообще полный URL) запоминаются в массиве. Когда формируется следующий запрос, то производится проверка наличия такого же в массиве; если дубликат обнаружен, то второй запрос отбрасывается (не грузим сервер). Соответственно при приеме ответов с сервера Вы должны удалить из стека запросов соответствующий запрос (на который пришел ответ).
Чтобы сильно не запутывать скажу еще, что этот же механизм стека позволяет контролировать ситуацию, когда младший запрос/ответ пришел самым последним (его нужно отбросить). Для этого в стеке надо также хранить время отправки запроса и проверять при приеме ответа с сервера. При этом устаревшие запросы помечаются как ненужные. Когда с сервера приходят запоздавшие ответы, то они уже помечены как устаревшие и пользователю не показываются. Остается только удалить эти запросы из стека.