Re: [reSIProcate] Frustration with TCP transport
Hi Paul,
The TCP based transports really need a pretty big overhaul. For this
particular problem, I think the best solution would be to provide
"better handling of the error condition, ideally opening a new socket
for the connection immediately". It would be great if you could post
a patch for this. : )
Thanks,
Scott
On Mon, Sep 14, 2009 at 11:19 AM, Paul Kurmas <pkurmas@xxxxxxxxxxxxx> wrote:
> I have frustration with the TCP transport – specifically with the behavior
> when an existing socket is “stale” and a write on the socket fails.
>
>
>
> TcpBaseTransport::processAllWriteRequests will create a new socket if there
> is no active connection, but there’s no verification that the socket is
> truly functional. Control passes into TcpBaseTransport::processSomeWrites
> (and below) where the write fails. There’s no feedback that the write has
> failed, so I’m stuck waiting for the protocol timer to declare the failure
> before a retry is possible. Meanwhile, another request enqueued gets
> processed just fine because TcpBaseTransport::processAllWriteRequests
> recognizes there is no connection available & opens a new one.
>
>
>
> Does the community have any vision of what a more complete handling of
> transmission error cases should look like? My sense is that either we
> should verify the socket is OK before sending (requires a write, probably)
> or provide better handling of the error condition, ideally opening a new
> socket for the connection immediately.
>
>
>
> Thanks for any feedback you may have.
>
> PK
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>