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 <[email protected]> Sent: Wednesday, November 23, 2016 2:56 PM To: [email protected] 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" <[email protected]> >> To: [email protected] >> 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
