Re: [sr-dev] [Fwd: Re: [Kamailio-Users] TCP supervisor process in Kamailio]

In async mode the sending can be done directly by a "worker" (a tcp reader process, a udp or sctp receiver) or by the supervisor. On a fresh connection (no write data queued), a worker will attempt to send directly. If it fails it enters async mode and it will queue the data. On a connection with data already queued (in "async mode"), the worker will directly queue the data (will not attempt sending directly anymore). All the "async" queued data is sent by the supervisor (in the future I might add some write workers if it proves to make a difference in tests). When all the async data was sent, the connection exists "async mode" (the next worker will try again to send directly). Almost all ser-side initiated connections will enter "async" mode when they are first opened (because the connect() takes time and during the connect phase the kernel does not queue any data on the socket, so we have to do it in ser). In async mode the send never blocks (with the same disclaimers as for the non-blocking read). If no "real" send happens for tcp_send_timeout (or tcp_connect_timeout if this is a not yet connected connection), the connection will be closed, a failure will be reported and the destination will be blacklisted. Same thing happens if the per connection queued data exceeds tcp_conn_wq_max or the total queued data in ser exceed tcp_wq_max. Note that there are two data queues: one in the kernel (the socket write buffer) and one in ser. Above by queued data I meant the data queued in ser and not in the kernel. Andrei _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev