Originally Posted By: argv0
Nothing is flawed, because it worked fine before. This is nothing but a regression. The design of the system is fine, and there's no need to break backwards compatibility and change functionality now. In any case, there's also no reason to add bloat by creating extra event-specific identifiers when a socket-specific identifier makes perfect sense in a single-threaded environment. In a single-threaded environment, per-socket data is *equivalent* to locally-scoped data.


When I say it is "flawed," I mean that it is more complicated than it needs to be. I also think it is confusing. After some more thought, I think I have reversed my opinion on the TCP-related calls. It makes sense that the remote IP and port aren't going to change during the course of a TCP connection's lifespan, so $sock().ip and $sock().port seem like reasonable ways to deal with TCP sockets.

However, the issue with UDP sockets is that each datagram will have a potentially different remote IP/port associated with it. In this manner, the $sock().sport and $sock().saddr information isn't actually tied to that socket name (since you can receive datagrams from multiple sources on that same socket name); instead, that data is tied to the individual datagram. This is why I think it makes more sense as a locally-scoped identifier for the UDPREAD event.

Ultimately, I think $udpaddr and $udpport from within the scope of ON UDPREAD make more sense in that it emphasizes that this information is only valid for that particular datagram and not for the socket in general. It may not matter in terms of functionality but it does seem like a more LOGICAL way to design it. It also seems possible (although I can only guess because we don't know the true cause) that the bug being discussed in this thread might not occur if the IP/port information was passed directly to the event instead.

Along the same lines, I'd like to see something like $sockip and $sockport in ON SOCKLISTEN events, to be able to access the remote IP/port that is connecting before accepting the connection.