You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2014/05/15 17:07:48 UTC
[API REVIEW] TSVConnFdCreat
Hi all,
I'm proposing a new API, TSVConnFdCreate.
TSVConn TSVConnFdCreate(int fd)
TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that wraps that file descriptor. The file descriptor must be a connected socket. The resulting TSVConn can be used with the standard TS I/O API. If the call returns successfully, the returned TSVConn owns the socket and the caller must not close(2) it. If TSVConnFdCreate() returns NULL, the socket is unchanged and the caller must for close(2) it.
My use case for this is to stitch a server intercept to an external API that vends a connected socket.
James
Re: [API REVIEW] TSVConnFdCreat
Posted by James Peach <jp...@apache.org>.
On May 16, 2014, at 11:28 AM, Bardwell, William <wb...@akamai.com> wrote:
> I love it...in fact I already implemented this against 3.2.X for a similar use. I called it TSVConnFromFdCreate(), I had it taking a mutex (that could be NULL) as well, but not sure if that is really needed.
I think the mutex might be needed if you deliver the NET_EVENT_OPEN events when you create the VConn. this API does not deliver those events; it succeeds or fails immediately
> (I liked the "From" part of the name to make it clear that it wasn't making and Fd inside the VConn...but same diff.)
Yeh, I think the name is a mixed bag. "From" is usually used with reference to the network data flow direction TSCacheKeyDigestFromUrlSet, INKUDPPacketFromPortGet, etc. TSVConnCreateFromFd scans better, but we do have a strong convention to end API names with the verb.
> In in turn called:
> NetVConnection *UnixNetProcessor::vconn_from_fd(int fd, ProxyMutex * mutex, NetVCOptions * opt)
> which is a pretty short variant of the code that is used to make a VConn after accept() or connect().
That sounds *very* like my patch :)
> (Sorry, I just hadn't had time yet to try to get legal approval to upstream the code.)
>
> -William
> ________________________________________
> From: James Peach [jpeach@apache.org]
> Sent: Friday, May 16, 2014 11:07 AM
> To: dev@trafficserver.apache.org
> Subject: Re: [API REVIEW] TSVConnFdCreat
>
> On May 15, 2014, at 8:07 AM, James Peach <jp...@apache.org> wrote:
>
>> Hi all,
>>
>> I'm proposing a new API, TSVConnFdCreate.
>>
>> TSVConn TSVConnFdCreate(int fd)
>>
>> TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that wraps that file descriptor. The file descriptor must be a connected socket. The resulting TSVConn can be used with the standard TS I/O API. If the call returns successfully, the returned TSVConn owns the socket and the caller must not close(2) it. If TSVConnFdCreate() returns NULL, the socket is unchanged and the caller must for close(2) it.
>>
>> My use case for this is to stitch a server intercept to an external API that vends a connected socket.
>
> FWIW, this is https://issues.apache.org/jira/browse/TS-2810
>
> J
RE: [API REVIEW] TSVConnFdCreat
Posted by "Bardwell, William" <wb...@akamai.com>.
I love it...in fact I already implemented this against 3.2.X for a similar use. I called it TSVConnFromFdCreate(), I had it taking a mutex (that could be NULL) as well, but not sure if that is really needed. (I liked the "From" part of the name to make it clear that it wasn't making and Fd inside the VConn...but same diff.)
In in turn called:
NetVConnection *UnixNetProcessor::vconn_from_fd(int fd, ProxyMutex * mutex, NetVCOptions * opt)
which is a pretty short variant of the code that is used to make a VConn after accept() or connect().
(Sorry, I just hadn't had time yet to try to get legal approval to upstream the code.)
-William
________________________________________
From: James Peach [jpeach@apache.org]
Sent: Friday, May 16, 2014 11:07 AM
To: dev@trafficserver.apache.org
Subject: Re: [API REVIEW] TSVConnFdCreat
On May 15, 2014, at 8:07 AM, James Peach <jp...@apache.org> wrote:
> Hi all,
>
> I'm proposing a new API, TSVConnFdCreate.
>
> TSVConn TSVConnFdCreate(int fd)
>
> TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that wraps that file descriptor. The file descriptor must be a connected socket. The resulting TSVConn can be used with the standard TS I/O API. If the call returns successfully, the returned TSVConn owns the socket and the caller must not close(2) it. If TSVConnFdCreate() returns NULL, the socket is unchanged and the caller must for close(2) it.
>
> My use case for this is to stitch a server intercept to an external API that vends a connected socket.
FWIW, this is https://issues.apache.org/jira/browse/TS-2810
J
Re: [API REVIEW] TSVConnFdCreat
Posted by James Peach <jp...@apache.org>.
On May 15, 2014, at 8:07 AM, James Peach <jp...@apache.org> wrote:
> Hi all,
>
> I'm proposing a new API, TSVConnFdCreate.
>
> TSVConn TSVConnFdCreate(int fd)
>
> TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that wraps that file descriptor. The file descriptor must be a connected socket. The resulting TSVConn can be used with the standard TS I/O API. If the call returns successfully, the returned TSVConn owns the socket and the caller must not close(2) it. If TSVConnFdCreate() returns NULL, the socket is unchanged and the caller must for close(2) it.
>
> My use case for this is to stitch a server intercept to an external API that vends a connected socket.
FWIW, this is https://issues.apache.org/jira/browse/TS-2810
J