qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "rajith attapattu" <rajit...@gmail.com>
Subject Re: Review Request: IPv6 support for C++ (Windows and Linux) client/broker and python
Date Wed, 10 Aug 2011 17:29:14 GMT


> On 2011-08-10 14:15:46, Gordon Sim wrote:
> > As you have noted the python client doesn't support the AMQP 0-10 defined url scheme.
The c++ messaging API consequently supports the form of url used by python in addition. That
code is in src/qpid/cpp/amqp_0_10/SimpleUrlParser.cpp and would (I believe) break for IPv6
addresses.
> 
> Andrew Stitcher wrote:
>     I didn't spot this code, what is it used for? It doesn't seem to have been in the
path for anything I tried. In other words nothing failed for not changing this parser.
>     
>     Incidentally why (oh why, oh why) do we have *two* parsers in C++ for the amqp_0_10
url scheme? I thought the one I fixed was that parser.
> 
> Gordon Sim wrote:
>     SimpleUrlParser does not parse the 0-10 URL scheme (i.e. that defined by the spec).
It was introduced to provide an alternative that was compatible with the form used by the
python client and is only used by the messaging API for URLs that don't begin with the 'amqp'
scheme identifier (the ipv6 test includes that identifier which is why it would not use this
codepath). However, looking at the latest URL code it appears that the qpid::Url class would
now be sufficient as it no longer restricts itself to the official scheme...
> 
> Gordon Sim wrote:
>     Fyi: I have now removed SimpleUrlParser (r1156262) so this point can be ignored.
> 
> Andrew Stitcher wrote:
>     Ah I understand, I think it would be nice to have a single compatible superset syntax
across all the implementations. I have an idea for something I think would work.

+1 on the single syntax across all implementations. The java client could certainly make use
of a better connection string syntax.
Something along the lines of "protocol://host:port; {k1:v1,.....kn:vn} would be nice, where
the optional set of properties allowing implementation specific properties in addition to
a bunch of common props across all clients.
A property value can be another map ex k:{...}, a list k:[] or just a string.


- rajith


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1440/#review1376
-----------------------------------------------------------


On 2011-08-09 22:26:16, Andrew Stitcher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1440/
> -----------------------------------------------------------
> 
> (Updated 2011-08-09 22:26:16)
> 
> 
> Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, Ted Ross, Steve Huston,
and Cliff Jansen.
> 
> 
> Summary
> -------
> 
> This is my proposed code change for C++ and Python to support IPv6:
> 
> It includes a few different items:
> 
> IPv6 support at the socket level
> - The C++ broker now listens on both TCPv4 and TCPv6 sockets for connections
>   and accepts from both in the regular tcp transport.
> - The C++ client will connect to both TCPv4 and TCPv6 connections. If a name
>   resolves to both v4 and v6 addresses they will be tried in turn as is
>   required for correct functioning in a mixed network.
> - The necessary Windows code is also present but more lightly tested.
> - The Python client will now similarly connect to v6 as well as v4 addresses
> 
> Connection URL syntax and parsing updated to include literal IPv6 addresses
> - For example "[::1]" is now allowed
> - C++ and Python URL parsers updated (very annoying that the parse different syntaxes)
> 
> Simple system test to the C++ build to smoke test IPv6 support.
> - This only uses the IPv6 loopback address though
> 
> I have this change broken down into smaller patches if anyone would rather see it that
way. It's just easier
> to put it up for review in one big glob.
> 
> 
> This addresses bugs QPID-3404, QPID-3405, QPID-3406, QPID-3407, and QPID-3409.
>     https://issues.apache.org/jira/browse/QPID-3404
>     https://issues.apache.org/jira/browse/QPID-3405
>     https://issues.apache.org/jira/browse/QPID-3406
>     https://issues.apache.org/jira/browse/QPID-3407
>     https://issues.apache.org/jira/browse/QPID-3409
> 
> 
> Diffs
> -----
> 
>   /trunk/qpid/cpp/src/qpid/Address.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/Url.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/broker/windows/SslProtocolFactory.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/Socket.h 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/SocketAddress.h 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/TCPIOPlugin.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/epoll/EpollPoller.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/posix/AsynchIO.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/posix/Socket.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/posix/SocketAddress.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/windows/AsynchIoResult.h 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/windows/Socket.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/windows/SocketAddress.cpp 1155572 
>   /trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.h 1155572 
>   /trunk/qpid/cpp/src/tests/Makefile.am 1155572 
>   /trunk/qpid/cpp/src/tests/Url.cpp 1155572 
>   /trunk/qpid/cpp/src/tests/cluster_test_logs.py 1155572 
>   /trunk/qpid/cpp/src/tests/ipv6_test PRE-CREATION 
>   /trunk/qpid/extras/qmf/src/py/qmf/console.py 1155572 
>   /trunk/qpid/python/qpid/util.py 1155572 
>   /trunk/qpid/tools/src/py/qpid-route 1155572 
> 
> Diff: https://reviews.apache.org/r/1440/diff
> 
> 
> Testing
> -------
> 
> Tested (amongst other things) with included system test
> Tested lightly by hand on Windows
> 
> 
> Thanks,
> 
> Andrew
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message