Perhaps I’m not understanding things, but i was hoping to use the peer class object that seems to come with TCPIP dat callbacks now to resolve where I’m getting a message from when a client TCPIP sends something back to the server TCPIP dat.
peer.address when debugged just says <attribute ‘address’ of ‘td.Peer’ objects> when i wrap it in a str(). When I don’t wrap it in a str() it tells me its not a string, despite what the documentation seems to say… I am just testing locally atm. Is this unfinished? Or am I being silly?
Ah thanks Ivan and Markus! the hint to check type(peer) was what i needed to realize i was sending “Peer” into my extension function instead of “peer”. I was getting confused by the type check/hint syntax being added everywhere for the new TDI stuff ( eg peer: Peer) derp! Still getting used to all the new python spiffy stuff. thanks!
Heya, sort of reviving this to mention something that came up today whilst troubleshooting on an install. We discovered upon testing on our multiple machine setup for a large install, that printing statements using the peer object’s address and hostname was causing extreme lagging for each message we were receiving into a TCP/IP DAT. This wasn’t evident in local testing on the same machine or even on a simpler network. We removed the printing of peer.hostname and peer.address and got rid of the lag. I assume something about the accessing of those attributes on the object was triggering some os level network polling that was exacerbated by the more complex network ( multiple NICs on each machine perhaps?). Figured I’d mention this in case it is perhaps a bug of some sort.
