Hi Fraser,
Thanks for the information provided.
I need the source port information for the purpose of allowing traffic
from my machine to the other machines.
So if i know the AMQP source port I can allow only the AMQP packets.
The netstat solution and the python scripts are of little help to me
since they give information after the packets leave the machine.
So for this purpose, if I can get this info from the qpid library,then
I can write rules for the traffic management.
Could you please suggest me any other alternative solution ?
Regards,
Sree.
> Date: Sun, 27 Jan 2013 09:10:55 +0000
> From: fraser.ad...@blueyonder.co.uk
> To: sys8...@hotmail.com
> Subject: Re: Amqp message sender port
>
> Hi Sree,
> I'm still not *entirely" sure what you are trying to achieve.
>
> So in your architecture as you've described it you have a single
> producer, a broker and multiple consumers.
>
> You say "To distinguish messages that are sent to different machines, I
> need to know the Source Port number from which the AMQP Message is sent
> " that confuses me a bit because you say you've got a single producer?
> So presumably all consumers would receive messages from that producer
> (assuming they had the correct bindings in place).
>
> I'm curious as to why you are interested in the source port on the
> source host. That feels a bit weird at a fundamental level as the
source
> port is an ephemeral port http://en.wikipedia.org/wiki/Ephemeral_port
> and so every time a Connection is made this port number will be
> different, so it's hard to see how you'd use it to "distinguish
messages
> that are sent to different machines ".
>
> I may be mistaken, but it sounds like you are interested in using some
> sort of information about the producer machine from the perspective of
> the consumer machine, is that correct? Remember that in an AMQP 0.10
> topology you have the message broker in play and producers and
consumers
> are decoupled (with one producer and multiple consumers I suspect that
> you are using a publish/subscribe model to the topic exchange, this is
> sometimes known as "fire and forget" as the producer generally doesn't
> know about consumers and vice-versa).
>
> To pass information from a producer to a consumer in a MoM architecture
> you'd (conceptually at least) design some form of "application
protocol"
> for passing information between endpoints (i.e. a protocol layered on
> top of the Messaging Protocol). That all sounds very grand, but in your
> case such a "protocol" can probably decompose into setting a message
> header with a particular value in the producer that the consumer can
> then retrieve and interpret. Although that's probably how you'd
> implement it I'd recommend that you do think of it like a protocol and
> design it with a well defined interface, because your application will
> be a lot easier to maintain in the long run if you do and your
producers
> and consumers will know where they stand.
>
> So passing arbitrary information from a producer to a consumer isn't
> hard, but if you *really do need* to find the ephemeral port of the
> underlying socket connection that is carrying the AMQP then that is I
> believe pretty hard because as I said in my previous post the APIs are
> deliberately designed to abstract that information (Qpid can actually
> use multiple transports including tcp and rdma). As I said earlier you
> *might* be able to down-cast from the API classes to implementation
> classes and find some way to navigate to the underlying socket
> connection. It's probably possible but I'd assert that doing that sort
> of thing is *evil hackery* and I really wouldn't recommend it.
>
> I have to be honest, I think that you are going about this from the
> wrong angle. My strong advice would be for you to take a deep breath
and
> a step back and consider what you really want to achieve at an
> architectural level. Going straight for an ephemeral port is almost
> certainly an "implementation decision" and in most cases unless you are
> doing some sort of network diagnostics unlikely to be what you "really
> want". I'd think first about what information you really want to pass
> between your producers and consumers at a logical level first, if you
> decide that it really is the ephemeral port of the AMQP socket
transport
> then fair enough, but I'd love to know the justification for such a
choice.
>
>
> If you *really* want to get at the ephemeral port after what I've said
> above as I say I can't think of a really easy way through any API and
> I'm not even sure how to hack the implementation classes to get at it,
> but there may be mileage in a slightly more lateral approach. I'm no
> expert, but running "netstat -an | grep 5672" on my Linux box yields
>
> tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN
> tcp 0 0 127.0.1.1:5672 127.0.0.1:43459 ESTABLISHED
> tcp6 0 0 127.0.0.1:43459 127.0.1.1:5672 ESTABLISHED
>
> Now running netstat from your application might be a pain, but I'd
> assume that in Linux netstat gets its info from the /proc filesystem.
>
> Looking at the results for cat /proc/net/tcp the results aren't as easy
> to interpret as netstat but 5672 is 1628 in hex so I did "cat
> /proc/net/tcp | grep 1628" and got:
>
> 3: 00000000:1628 00000000:0000 0A 00000000:00000000 00:00000000
> 00000000 1000 0 6199631 1 0000000000000000 300 0 0 2 -1
> 129: 0101007F:1628 0100007F:A9C3 01 00000000:00000000 00:00000000
> 00000000 1000 0 9622157 1 0000000000000000 20 4 0 10 -1
>
> The first result is the listen on the wildcard address, but the second
> is what you want 0101007F is clearly 127.0.1.1, 1628 is hex for 5672,
> 0100007F is 127.0.0.1 and A9C3 is hex for 43459.
>
>
> Clearly if you have multiple clients on the same host connecting to
5672
> then the results will be a whole lot harder to interpret and obviously
> you'd need to write something to read and parse /proc/net/tcp
>
> I really wouldn't recommend any of this and my previous comments on
> thinking about what you're really trying to achieve stand, but if you
> really want to hopefully some of this helps.
>
> Regards,
> Frase
>
>
> On 27/01/13 04:18, sys8...@hotmail.com wrote:
> > Hi Frase
> >
> > I am sending AMQP Messages from one machine to multiple machines.
> > To distinguish messages that are sent to different machines,
> > I need to know the Source Port number from which the AMQP Message
is sent from the sender machine (including all the amqp packets that
leave the sender machine).
> >
> > I tried using the APIs in the qpid::sys::SystemInfo namespace,but
it gives the destination IP and Port information which is of little
help to me.
> >
> > Is there any other way to get the Source Port number ?
> >
> > I am using qpid 0-10 C++ api
> > The destination Port I use is always 5672.
> >
> > Thanks
> > Sree.
> >
> > <quote author='fadams'>
> > Hello,
> > what's the objective that you are trying to achieve?
> >
> > Do you mean that you want a producer client to be able to work out the
> > source port the connection is using, or given a producer client, a
> > broker and a consumer client you want to figure out from the
broker say
> > what the source port is on inbound connections?
> >
> > I don't thing either scenario is necessarily trivial.
> >
> > In the first scenario if you are in Qpid Client code you normally
use an
> > API such as qpid::messaging in C++ or JMS in Java to provide an
> > abstraction for creating a Connection, a Session etc.
> >
> > In a Messaging system these abstractions tend to be pretty high level,
> > so for example with JMS I'm pretty certain that there's not any way in
> > the API to retrieve the underlying Socket or InetAddr. You *might* be
> > able to get to the Socket by down-casting to the Qpid specific class
> > that is implementing javax.jms.Connection and digging around there
> > (similar for qpid::messaging) but it's not certain if this is even
> > exposed on a public method on a private class.
> >
> >
> > If it's the second scenario then it's not trivial but it is
exposed, the
> > QMF connection ManagementObject exposes the host and port info for
both
> > sides in the address property (the old 0.8 broker only exposed one end
> > but from 0.10 both sides are exposed).
> >
> > The Qpid GUI that I recently posted info on exposes all of this
and it's
> > pretty easy to see most things one is likely to care about.
> >
> > If you need to look at this in your own code you might want to take a
> > look at a posting I sent in reply to Lance D. on the topic of
> > "Instrumenting the Broker" (around the 11th of January). I posted
him a
> > couple of python programs I'd written (connection-logger and
> > connection-audit) those illustrate how to get connection info (plus a
> > load else) out of the broker via QMF. The might well help you get
up and
> > running.
> >
> > HTH,
> > Frase
> >
> >
> >
> > On 26/01/13 16:16, sys8284 wrote:
> >> HI
> >>
> >> How can i get the sender port number i.e .., the port from which
the AMQP
> >> Message is sent from Source Computer
> >>
> >> I know the destination port as 5672. But i need the origin port
number
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
http://qpid.2158936.n2.nabble.com/Amqp-message-sender-port-tp7587517.html
> >> Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
> > </quote>
> > Quoted from:
> >
http://qpid.2158936.n2.nabble.com/Amqp-message-sender-port-tp7587517p7587519.html
>
