qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Patierno <ppatie...@live.com>
Subject Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port
Date Wed, 23 Nov 2016 15:00:28 GMT
Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted ..." line but it's
not necessary.


So just a new log line after that when the transport reference is available to the router.


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno<http://twitter.com/ppatierno>
Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno>
Blog : DevExperience<http://paolopatierno.wordpress.com/>


________________________________
From: Ted Ross <tross@redhat.com>
Sent: Wednesday, November 23, 2016 2:56 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port



On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
>
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <robbie.gemmell@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Wednesday, November 23, 2016 7:58:48 AM
>> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and remote
IP/port
>>
>> On 23 November 2016 at 08:04, Paolo Patierno <ppatierno@live.com> wrote:
>>> Hi,
>>>
>>>
>>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
>>> Dispatch Router, I need sometimes to know who is the remote peer is
>>> exchanging traced messages.
>>>
>>>
>>> For example, considering these few lines of trace (running the Qpid
>>> Dispatch Router) :
>>>
>>>
>>> Accepted from 127.0.0.1:48192
>>> Accepted from 127.0.0.1:48190
>>> [0x7fbc44016390]:  <- SASL
>>> [0x7fbc44016390]:  -> SASL
>>> [0x7fbc44003b70]:  <- SASL
>>> [0x7fbc44003b70]:  -> SASL
>>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>>
>>>
>>> The router accepts two connections from remote clients (we see IP and port)
>>> but then every message is related to an "identifier" (I guess it should be
>>> the file descriptor related to the used socket).
>>>
>>
>> I think the 'identifier' will actually relate to the proton transport,
>> e.g its address, since the engine doesnt know about the socket.
>>
>>> If I need to match these information with Wireshark (where I can see remote
>>> port) I don't know if remote clients using remote port 48192 is related to
>>> 0x7fbc44016390 or 0x7fbc44003b70.
>>>
>>>
>>> I think it could be a good information to add into the trace at least
>>> showing the "identifier" after the accepted message, i.e. :
>>>
>>>
>>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> I don't think we can display the proton transport reference (0x7fbc44016390) next to
the host/ephemeral port because we don't have a transport yet. Dispatch router code is accepting
the connection in src/driver.c function qdpn_listener_accept() and proton is not in the picture
yet.

If we could issue a log once the transport is created that has the
transport reference and the host/port, that would solve the problem.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


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