I think it should be OK. It uses ink_inet_port_cast which extracts the port
without changing byte order. TSNetConnect used ink_inet_get_port which flips
the byte order. I think I will add it to the patch to not bother to extract the
address and port (that was needed before the changes in 3.1.0).
After looking at 3.1.0, is it possible that TSFetchUrl might also have
the same problem?
On Tue, Aug 23, 2011 at 9:48 AM, Alan M. Carroll
wrote:
> Because of the change over to IPv6 in the internals, ports are stored
> differently. Let me take a look ...
>
> Yeah, that's a bug introduced by the
Because of the change over to IPv6 in the internals, ports are stored
differently. Let me take a look ...
Yeah, that's a bug introduced by the change. A quick fix is to change
InkAPI.cc:6196 from
return (TSAction)netProcessor.connect_re(i, ip, port);
to
return (TSAction)netProcessor.connect_r
Hi,
The trunk code version of TSNetConnect now seems to take a host byte ordered
port number. Previously (i.e. 3.0.0) took the network byte order. I.e. I now
have to use the ntohs function on the port number.
Is this by design?
Thank-you,
Chris Reynolds.
