Что такое синхронные и асинхронные вызовы
Перейти к содержимому

Что такое синхронные и асинхронные вызовы

  • автор:

Синхронные и асинхронные операции

В этом разделе описывается реализация и вызов асинхронных операций службы.

Многие приложения вызывают методы асинхронно, поскольку это позволяет приложению продолжать выполнение других операций, пока осуществляется вызов метода. Службы и клиенты WCF (Windows Communication Foundation) могут участвовать в асинхронных вызовах операций на двух различных уровнях приложения, которые обеспечивают приложениям WCF большую гибкость для увеличения пропускной способности без ущерба для интерактивности.

Типы асинхронных операций

Все контракты служб в WCF не зависят от типов параметров и возвращаемых значений и используют атрибуты WCF, чтобы определить конкретный шаблон обмена сообщениями между клиентом и службой. WCF автоматически направляет входящие и исходящие сообщения в соответствующую операцию службы или исполняемый код клиента.

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

Независимость контракта службы от реализации службы и клиента делает возможными следующие формы асинхронного выполнения в приложениях WCF:

  • клиенты могут вызывать операции запроса и ответа асинхронно, используя синхронный механизм обмена сообщениями;
  • службы могут реализовывать операции запроса и ответа асинхронно, используя синхронный механизм обмена сообщениями;
  • обмен сообщениями может быть односторонним независимо от реализации клиента или службы.

Предлагаемые асинхронные сценарии

Асинхронный подход следует использовать при реализации операции службы, если реализация операции службы осуществляет блокирующий вызов, например операцию ввода-вывода. При реализации асинхронной операции попробуйте вызывать асинхронные операции и методы, чтобы, насколько это возможно, расширить функции асинхронного вызова. Например вызовите метод BeginOperationTwo() из метода BeginOperationOne() .

  • Асинхронный подход следует использовать в клиенте или вызывающем приложении в следующих случаях.
  • Если операции вызываются из приложения промежуточного уровня. (Дополнительные сведения о таких сценариях см. в статье о клиентских приложениях среднего уровня.)
  • Если операции вызываются на страницах ASP.NET, следует использовать асинхронные страницы.
  • Если операции вызываются из любого однопотокового приложения, например приложения Windows Forms или WCF (Windows Presentation Foundation). При использовании модели асинхронных вызовов на основе событий результирующее событие создается в потоке пользовательского интерфейса, в результате чего приложение получает возможность реагирования на действия пользователя, но при этом не требуется управлять несколькими потоками.
  • В общем случае при выборе между синхронным и асинхронным вызовом следует выбирать асинхронный вызов.

Реализация асинхронной операции службы

Асинхронные операции могут быть реализованы с помощью одного из трех следующих методов:

  1. асинхронная модель на основе задач;
  2. асинхронная модель на основе событий;
  3. асинхронная модель IAsyncResult.
Асинхронная модель на основе задач

Асинхронная модель на основе задач — это предпочтительный способ реализации асинхронных операций в силу его чрезвычайного удобства и простоты. Чтобы использовать этот метод, просто реализуйте операцию службы и укажите тип возвращаемой задачи, где T — тип, возвращаемый логической операцией. Например:

public class SampleService:ISampleService < // . public async TaskSampleMethodTaskAsync(string msg) < return Task.Factory.StartNew(() => < return msg; >); > // . > 

При использовании асинхронной модели на основе задач может быть вызван объект T:System.AggregateException в случае возникновения исключения во время ожидания завершения операции. Это исключение может возникнуть на стороне клиента или службы

Асинхронная модель на основе событий

Служба, поддерживающая асинхронную модель на основе событий, будет содержать одну или несколько операций с именем MethodNameAsync. Эти методы могут копировать синхронные версии, выполняющие ту же операцию в текущем потоке. Этот класс также может содержать событие MethodNameCompleted, а также метод MethodNameAsyncCancel (или просто CancelAsync). Клиент, вызывающий операцию, определяет обработчик событий, вызываемый после завершения операции.

В следующем фрагменте кода показано объявление асинхронных операций с помощью асинхронной модели на основе событий.

public class AsyncExample < // Synchronous methods. public int Method1(string param); public void Method2(double param); // Asynchronous methods. public void Method1Async(string param); public void Method1Async(string param, object userState); public event Method1CompletedEventHandler Method1Completed; public void Method2Async(double param); public void Method2Async(double param, object userState); public event Method2CompletedEventHandler Method2Completed; public void CancelAsync(object userState); public bool IsBusy < get; >// Class implementation not shown. > 

Дополнительные сведения об асинхронной модели на основе событий см. в этой статье.

Асинхронная модель IAsyncResult

Операция службы может быть реализована в асинхронном режиме с помощью платформа .NET Framework асинхронного шаблона программирования и маркировки метода с заданным true свойствомAsyncPattern. В этом случае асинхронная операция доступна в метаданных так же, как и синхронная операция: она предоставляется в виде одной операции с сообщением запроса и согласованным с ним сообщением ответа. В этом случае имеется возможность выбора одной из двух моделей программирования клиента. Этот шаблон может быть представлен в них в виде синхронной или асинхронной операции, поскольку при вызове службы имеет место обмен сообщениями «запрос-ответ».

В целом в связи с асинхронной природой систем полагаться на потоки не следует. Самый надежный способ передачи данных на различные этапы обработки диспетчеризации операций — это использование расширений.

Чтобы определить операцию контракта X , которая выполняется асинхронно независимо от того, как она вызывается в клиентском приложении, выполните следующие действия:

  • Определите два метода, используя шаблон BeginOperation и EndOperation .
  • Метод BeginOperation включает параметры in и ref для операции и возвращает значение типа IAsyncResult.
  • Метод EndOperation включает параметр IAsyncResult, а также параметры out и ref , и возвращает результат возвращаемого типа операции.

См., например, следующий метод.

int DoWork(string data, ref string inout, out string outonly) 
Function DoWork(ByVal data As String, ByRef inout As String, _out outonly As out) As Integer 

Для создания асинхронной операции эти два метода должны иметь следующий вид.

[OperationContract(AsyncPattern=true)] IAsyncResult BeginDoWork(string data, ref string inout, AsyncCallback callback, object state); int EndDoWork(ref string inout, out string outonly, IAsyncResult result); 
 Function BeginDoWork(ByVal data As String, _ ByRef inout As String, _ ByVal callback As AsyncCallback, _ ByVal state As Object) As IAsyncResult Function EndDoWork(ByRef inout As String, ByRef outonly As String, ByVal result As IAsyncResult) As Integer 

Атрибут OperationContractAttribute применяется только к методу BeginDoWork . В получаемом контракте имеется одна операция WSDL с именем DoWork .

Асинхронные вызовы на стороне клиента

Клиентское приложение WCF может использовать любую из трех описанных выше моделей асинхронных вызовов.

При использовании модели на основе задач просто вызовите операцию, используя ключевое слово «await», как показано в следующем фрагменте кода.

await simpleServiceClient.SampleMethodTaskAsync("hello, world"); 

Использование асинхронной модели на основе событий требует добавления обработчика событий для получения уведомлений об ответе. Результирующее событие будет создано в потоке пользовательского интерфейса автоматически. Чтобы воспользоваться этим подходом, укажите параметры командной строки /async и /tcv:Version35 в служебном средстве ServiceModel Metadata Utility Tool (Svcutil.exe), как показано в следующем примере.

svcutil http://localhost:8000/servicemodelsamples/service/mex /async /tcv:Version35 

В такой конфигурации служебная программа Svcutil.exe создает класс клиента WCF с инфраструктурой событий, которая позволяет вызывающему приложению реализовать и присвоить обработчик событий, который получает ответ и выполняет соответствующие действия. Полный пример такой реализации см. в статье Практическое руководство. Асинхронный вызов операций службы.

Однако асинхронная модель на основе событий доступна только в платформа .NET Framework 3.5. Кроме того, он не поддерживается даже в платформа .NET Framework 3.5 при создании клиентского канала WCF с помощью System.ServiceModel.ChannelFactory . Для асинхронного вызова операций в объектах клиентского канала WCF необходимо использовать объекты System.IAsyncResult. Чтобы воспользоваться этим подходом, укажите параметр командной строки /async в служебном средстве ServiceModel Metadata Utility Tool (Svcutil.exe), как показано в следующем примере.

svcutil http://localhost:8000/servicemodelsamples/service/mex /async 

В результате будет создан контракт службы, в котором каждая операция моделируется в виде метода , где свойство AsyncPattern имеет значение true , и соответствующего метода . Полный пример с использованием ChannelFactory см. в статье Практическое руководство. Асинхронный вызов операций с использованием фабрики каналов.

В любом случае приложения могут вызывать операцию асинхронно, даже если служба реализована синхронно, так же, как приложение может использовать один и тот же шаблон для асинхронного вызова и вызова локального синхронного метода. Реализация операции не является значительной для клиента; При поступлении сообщения ответа его содержимое отправляется в асинхронный < End >метод клиента, а клиент получает информацию.

Шаблоны одностороннего обмена сообщениями

Можно создать асинхронный шаблон обмена сообщениями, в котором односторонние операции (операции, у которых свойство OperationContractAttribute.IsOneWay имеет значение true и нет согласованного ответа) могут отправляться в любом направлении клиентом или службой независимо от противоположной стороны. (Для этого используется шаблон обмена дуплексными сообщениями с односторонней рассылкой сообщений.) В этом случае контракт службы указывает односторонняя обмен сообщениями, который можно реализовать как асинхронные вызовы или реализации, или нет. Обычно, если контракт определяет односторонний обмен сообщениями, реализации бывают преимущественно асинхронными, поскольку после отправки сообщения приложение не дожидается ответа и продолжает выполнять другие операции.

Асинхронные клиенты на основе событий и контракты сообщений

Согласно правилам разработки для асинхронной модели на основе событий, если возвращается несколько значений, одно значение возвращается как свойство Result , а остальные возвращаются как свойства объекта EventArgs. Одним из результатов этого является то, что если клиент импортирует метаданные с использованием параметров асинхронных команд на основе событий и операция возвращает более одного значения, объект EventArgs по умолчанию возвращает одно значение как свойство Result , а остальные являются свойствами объекта EventArgs.

Если требуется получать объект сообщения как свойство Result , чтобы возвращаемые значения были свойствами этого объекта, следует использовать параметр командной строки /messageContract. При этом формируется сигнатура, которая возвращает ответное сообщение как свойство Result объекта EventArgs. Все внутренние возвращаемые значения тогда будут свойствами объекта ответного сообщения.

Синхронность и асинхронность процессов

Мир может многому научиться у программистов. Он и так учится, только не тому и не так. Например, взял процессы и алгоритмы, но не заметил такого подхода, как асинхронность.

Любому программисту понятно, что такое синхронность и асинхронность. Вот насколько это понятно программисту, настолько это непонятно и обычным разработчикам процессов.

Синхронные действия процесса – те, которые выполняются в основном потоке, в рамках одного экземпляра процесса. Ключевое отличие синхронного режима: следующее действие начинается только тогда, когда завершено предыдущее. Соответственно, пока одно действие не завершено, процесс стоит колом.

Асинхронные действия – те, которые выполняются параллельно основному потоку, либо в том же экземпляре процесса, либо вообще в другом процессе. Ключевое отличие асинхронного режима: параллельное выполнение двух и более ветвей процесса.

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

Например, тот же процесс закупок по заявке. Рисуется стандартно, как последовательность действий: появилась заявка, снабженец выбирает поставщика, запрашивает сроки и стоимость, согласует с продавцом или отделом внутреннего контроля, формирует заказ поставщику, запрашивает в юридическом отделе или в бухгалтерии оценку контрагента, создает заявку на оплату, ждет этой оплаты, отслеживает заказ, потом организует или отслеживает оприходование на складе, чтобы, в конце концов, закрыть заявку. Процесс полностью синхронен.

Теперь представим – в нашей информационной системе не подключен сервис оценки поставщиков. Значит, юридическому отделу нужно собирать информацию из открытых источников. Значит, на выполнение оценки требуется время. С учетом очереди заявок к юристам, пройдет дня три.

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

Можем мы здесь добавить асинхронности? Конечно. В тот момент, когда снабженец выбрал поставщика, он может отправить заявку на оценку контрагента в юридический отдел, а сам пока будет вести переговоры, согласовывать цены и сроки. К тому моменту, когда он будет готов разместить заказ, и оценка подоспеет. Процесс закончится раньше на три дня.

Конечно, юристы могут возмутиться – чего это мы будем оценивать поставщика, если вы там еще четко не решили, будете ли у него заказывать? Что им ответить?

Решение напрашивается само собой, выше мы его уже обозначили – подключить сервис оценки поставщиков. Теперь мы еще лучше понимаем, зачем оно нужно – для придания асинхронности и ускорения процесса. Хотя, сервис, наверное, будет как раз синхронным. Как думаете?

Если сервис не подключать, то можно оправдать такую оценку работой «впрок». Если в вашей информационной системе есть куда записать данные оценки, то в следующий раз, когда возникнет потребность в работе с этим поставщиком, обращаться в юридический отдел уже не придется. Конечно, у оценки есть срок годности, но в некоторых разумных пределах ей пользоваться можно.

В асинхронности обычно пугает отсутствие гарантий, то есть риск негативного результата в одной из параллельных ветвей процесса. Что делать, если согласование закончится неудачей?

Тут нужна статистика. Если вы работаете с существующим процессом, то примерно, или точно, представляете себе, как часто определенные действия заканчиваются негативно – например, согласования. Вот из этой вероятности и стоит исходить, запуская параллельное выполнение.

Асинхронность прям напрашивается во все процессы согласования. Если там работать только по синхронному режиму, да еще и идти на поводу у согласующих, то выстраиваются длинные, взаимозависимые цепочки, порождающие бюрократию и круговую поруку.

Типичный пример: «я буду согласовывать только после того, как согласует вот он». Или «я посмотрю на этот договор только после финансистов». Хотя, если верить статистике и здравому смыслу, подобные постановки не имеют под собой оснований, и являются лишь способом переложить ответственность.

Тут главное – не переживать, и не браться за все сразу. Попробуйте выделить в асинхронный режим сначала одну ветвь согласования. Возможно, потребуется пересмотреть задание, параметры согласования – так, чтобы исключить взаимозависимость.

Например, пусть финансовый отдел, стоящий в цепочке согласования договора, смотрит только на условия оплаты. Пусть у него будут свои, понятные критерии оценки. Лучше, если они будут формализованы в виде типового договора – например, 100% постоплата для поставщиков, 100 % предоплата для покупателей. В таком случае договоры, удовлетворяющие критериям, будут проскакивать на раз. И у финансистов не останется повода ждать оценки от тех же юристов.

Единственное, что важно: асинхронные процессы очень сложно реализовать без автоматизации. Если процессы, их исполнение и отслеживание реализованы только на бумаге, то добавление параллельных ветвей превратит их в хаос. Нужна автоматизация.

Лучше всего для такой автоматизации подходит принцип «Автозадачи». Хотя, можно обойтись и стандартными средствами рисования процессов, которые есть в современных платформах, только придется повозиться.

Стандартные «рисовалки» процессов потребуют от вас обозначить весь процесс, все ветви и взаимосвязи. Если процесс сложный и длинный, то вы столкнетесь с проблемой – он банально перестанет влезать на экран, в ширину. Если вы учились в институте на программиста, то помните такое правило оформления алгоритмов: не более трех параллельных вертикальных ветвей. Правило придумано не просто так – если ветвей будет больше, понять схему алгоритма будет проблематично.

Автозадачи от этой проблемы избавляют – там изображения процесса нет вообще, т.к. отсутствует такая сущность – процесс. Есть задачи. Если очень хочется, можно из них собрать процесс. Но не наоборот. Эдакий дедуктивный метод рисования процессов.

Кроме асинхронности, есть еще более мощный метод оптимизации – буферизация процессов. О нем – в другой раз.

  • Анализ и проектирование систем
  • Управление персоналом

Как выполняются синхронные и асинхронные вызовы?

Всем привет. Столкнулся с таким вопросом на System Analyst в одной фирме. Спросили что такое асинхронные и синхронные вызовы, тут все понятно. Но вот следующий вопрос поставил в тупик.

А как обрабатываются синхронные и асинхронные вызовы на сервере (в сервисе)? Подозреваю, что вопрос в том, что происходит под капотом сервиса когда к нему прилетело два async вызова? Как он их обрабатывает, последовательно или параллельно?

Например моим предположением было то, что вызовы поступают в сервис вместе, внутри обрабатываются поочередно, и отдаются вместе.

  • Вопрос задан более года назад
  • 191 просмотр

1 комментарий

Простой 1 комментарий

Синхронные и асинхронные запросы

XMLHttpRequest поддерживает как синхронные, так и асинхронные запросы. В основном предпочтительно использовать асинхронные запросы вместо синхронных из-за соображений производительности.

Синхронный запрос приводит к выполнению кода, который «блокирует» взаимодействие с вкладкой браузера до тех пор, пока запрос не будет полностью выполнен, что существенно ухудшает отклик страницы.

Асинхронные запросы

Если вы используете асинхронный режим XMLHttpRequest , то после того, как данные будут получены, будет вызвана функция обработчик. Это позволяет браузеру работать нормально пока ваш запрос будет обрабатываться.

Пример: отправка запроса и получение файла ответа

Приведём простейший пример асинхронного запроса XMLHttpRequest .

var xhr = new XMLHttpRequest(); xhr.open("GET", "/bar/foo.txt", true); xhr.onload = function (e)  if (xhr.readyState === 4)  if (xhr.status === 200)  console.log(xhr.responseText); > else  console.error(xhr.statusText); > > >; xhr.onerror = function (e)  console.error(xhr.statusText); >; xhr.send(null); 

2 строка. 3 параметр метода open установлен как true для того, чтобы явно указать, что этот запрос будет обрабатываться асинхронно.

3 строка. Создаётся функция обработчик события onload . Этот обработчик следить за параметром readyState , для того, чтобы определить завершена ли передача данных и если это так и HTTP статус 200, то полученные данные выводятся в консоль. А если в результате передачи данных возникла ошибка, то сообщение об ошибки будет выведено в консоль.

15 строка. Происходит инициализация отправки запроса. Функция обработчик будет вызываться каждый раз, как будет происходить изменения состояния данного запроса.

Пример: создание стандартной функции для чтения внешних файлов

В разных сценариях существует необходимость принимать внешние файлы (ответ от сервера, к примеру, json файл). Это стандартная функция, которая использует XMLHttpRequest объект асинхронно, чтобы передать прочитанный контент в специальную функцию обработчик.

function xhrSuccess()  this.callback.apply(this, this.arguments); > function xhrError()  console.error(this.statusText); > function loadFile(url, callback /*, opt_arg1, opt_arg2, . */)  var xhr = new XMLHttpRequest(); xhr.callback = callback; xhr.arguments = Array.prototype.slice.call(arguments, 2); xhr.onload = xhrSuccess; xhr.onerror = xhrError; xhr.open("GET", url, true); xhr.send(null); > 
function showMessage(message)  console.log(message + this.responseText); > loadFile("message.txt", showMessage, "New message!\n\n"); 

Сигнатура вспомогательной функции LoadFile следующая: 1 аргумент — URL адрес для запроса (через HTTP GET), 2 аргумент — функция, которая будет вызвана после успешного выполнения ajax запроса и 3 аргумент — список аргументов, которые будут передаваться через XHR объект в функцию, которая была указана во 2 аргументе.

Строка 1 определяет функцию, которая будет вызвана, когда ajax запрос завершиться успешно. В свою очередь это вызовет функции callback, которая была указана в вызове функции loadFile (то есть функция showMessage ) которая была обозначена как свойство XHR объекта (строка 11). Дополнительные аргументы, которые были указаны при вызове функции loadFile , подставляются в вызов callback функции.

Строка 5 определяет функцию, которая будет вызвана в случаи, если ajax запрос не сможет завершиться успешно.

Строка 11 сохраняет в XHR объекте функцию, которая будет вызвана после успешного завершения ajax запроса. (эта функция передаётся 2 аргументов в вызове функции loadFile ).

12 строка срезает псевдомассив аргументов, который был передан при вызове функции loadFile . Начиная с 3 аргумента все аргументы будут хранится в массиве arguments объекта xhr , который передаётся в функцию xhrSuccess и в конечном итоге будут использованы при вызове функции showMessage , которая будет вызвана функцией xhrSuccess .

Строка 15 устанавливает true для 3 параметра, что явно указывает на то, что запрос будет выполняться асинхронно.

Строка 16 инициализирует запрос.

Пример: использование timeout

При использовании асинхронных запросов, можно установить максимальное время ожидания ответа от сервера. Это делается путём установки значения свойства timeout XMLHttpRequest объекта, как показано ниже:

function loadFile(url, timeout, callback)  var args = Array.prototype.slice.call(arguments, 3); var xhr = new XMLHttpRequest(); xhr.ontimeout = function ()  console.error("The request for " + url + " timed out."); >; xhr.onload = function ()  if (xhr.readyState === 4)  if (xhr.status === 200)  callback.apply(xhr, args); > else  console.error(xhr.statusText); > > >; xhr.open("GET", url, true); xhr.timeout = timeout; xhr.send(null); > 

Отметим, что в код была добавлена функция обработчик события ontimeout .

function showMessage(message)  console.log(message + this.responseText); > loadFile("message.txt", 2000, showMessage, "New message!\n"); 

2 аргумент функции loadFile устанавливает время ожидание равное 2000ms.

Примечание: Поддержка timeout была добавлена начиная с Gecko 12.0.

Synchronous request

Примечание: Starting with Gecko 30.0, Blink 39.0, and Edge 13, synchronous requests on the main thread have been deprecated due to the negative effects to the user experience.

Synchronous XHR often causes hangs on the web. But developers typically don’t notice the problem because the hang only manifests during poor network conditions or slow server response. Synchronous XHR is now in deprecation state. Developers are recommended to move away from the API.

All new XHR features such as timeout or abort aren’t allowed for synchronous XHR. Doing so would invoke InvalidAccessError .

Example: HTTP synchronous request

This example demonstrates how to make a simple synchronous request.

var request = new XMLHttpRequest(); request.open("GET", "/bar/foo.txt", false); // `false` makes the request synchronous request.send(null); if (request.status === 200)  console.log(request.responseText); > 

Line 3 sends the request. The null parameter indicates that no body content is needed for the GET request.

Line 5 checks the status code after the transaction is completed. If the result is 200 — HTTP’s «OK» result — the document’s text content is output to the console.

Example: Synchronous HTTP request from a Worker

One of the few cases in which a synchronous request does not usually block execution is the use of XMLHttpRequest within a Worker .

example.html (the main page):

doctype html> html> head> meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> title>MDN Exampletitle> script type="text/javascript"> var worker = new Worker("myTask.js"); worker.onmessage = function (event)  alert("Worker said: " + event.data); >; worker.postMessage("Hello"); script> head> body>body> html> 

myFile.txt (the target of the synchronous XMLHttpRequest invocation):

Hello World!!

myTask.js (the Worker ):

.onmessage = function (event)  if (event.data === "Hello")  var xhr = new XMLHttpRequest(); xhr.open("GET", "myFile.txt", false); // synchronous request xhr.send(null); self.postMessage(xhr.responseText); > >; 

Примечание: The effect, because of the use of the Worker , is however asynchronous.

It could be useful in order to interact in the background with the server or to preload some content. See Using web workers for examples and details.

Adapting Sync XHR usecases to the Beacon API

There are some cases in which the synchronous usage of XMLHttpRequest was not replaceable, like during the window.onunload and window.onbeforeunload (en-US) events. You should consider using the fetch API with keepalive flag. When fetch with keepalive isn’t available, you can consider using the navigator.sendBeacon API can support these use cases typically while delivering a good UX.

The following example (from the sendBeacon docs) shows a theoretical analytics code that attempts to submit data to a server by using a synchronous XMLHttpRequest in an unload handler. This results in the unloading of the page to be delayed.

.addEventListener("unload", logData, false); function logData()  var client = new XMLHttpRequest(); client.open("POST", "/log", false); // third parameter indicates sync xhr. :( client.setRequestHeader("Content-Type", "text/plain;charset=UTF-8"); client.send(analyticsData); > 

Using the sendBeacon() method, the data will be transmitted asynchronously to the web server when the User Agent has had an opportunity to do so, without delaying the unload or affecting the performance of the next navigation.

The following example shows a theoretical analytics code pattern that submits data to a server by using the sendBeacon() method.

.addEventListener("unload", logData, false); function logData()  navigator.sendBeacon("/log", analyticsData); > 

Смотрите также

  • Использование XMLHttpRequest
  • navigator.sendBeacon

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *