>>On Wed, 11 May 2005 22:48:31 -0400, rumours say that "Terry Reedy" >><[EMAIL PROTECTED]> might have written: >>>play an online action game, which sends a constant stream of update >>>info. >>>Then, curious what would happen, I logged on, from a different computer >>>but >>>through the same router, with a temporary guest account. Somewhat to my >>>surprise, it worked -- without touching the computer (XP) or router >>>settings. And kept working the whole weekend. So there is a way to tag >>>update packets so they can be reliably separated into two streams (and >>>vice >>>versa). Solipsis should be able to do the same.
> 7On Sat, 14 May 2005 02:28:57 +0300, Christos TZOTZIOY Georgiou > <[EMAIL PROTECTED]> wrote: >>In your case, it's the internal address that originated the connection-- >>so the router can distinguish the streams: >> >>(int1, port1)->(ext_host, port0) >>maps to (router_ext, port2)->(ext_host, port0) >> >>(int2, port3)->(ext_host, port0) >>maps to (router_ext, port4)->(ext_host, port0) Thank you for answering my implicit question. If I understand now, the point I had previously missed is that even though an Internet service must typically be addressed *to* a particular port, it does not, typically, have to be address *from* that particular port. So the NAT translator is free to associate the doubleton (internal address, internal port) to external source port (as long as computers X average ports in use < 64K). >>However, if both of your internal computers listen to port 6000 for >>example, there is no easy way for the router to know to which one it >>should forward an *incoming* request for connection to port 6000 In my case, both computers separately originated their sessions. So apparently, the game company, while listening on port X, is willing to service two different sessions for two different accounts to different client ports, even at the same address, perhaps anticipating and hoping that two or more people behind a firewall might buy accounts. I could then see a multiplexing problem for Solipsis or similar peer-to-peer schemes if everyone, being a server as well as client, is required to listen and send to just one port. "Jp Calderone" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Combinations of marginally smart routers and non-broken protocols can > deal with even this situation automatically, without user configuration > or intervention. > > Traffic to (router_ext, N) from (ext, M) can be switched to (int1, N) or > (int2, N) by simply noticing which of int1 or int2 has recently sent > traffic from N to (ext, M). This is what I imagined the router doing. In the case I noted, there was/is a steady stream of updates to both clients even if they send nothing (due to not moving or clicking on anything), so this would not work. That is why I was a bit surprised when it did work. > If both have, you can still generally figure it out, by rewriting the > source port >automatically on the router. I presume you are referring here to what Christos described. I now assume that this is what my NetGear was doing. > Of course, if your protocol includes port numbers in the application > areas of >the packets it sends, the router usually can't properly rewrite > the packet, so >things go pear shaped. 'Pear shaped' is an interesting metaphor for what I anticipated. But I did not definitely notice a single misdirected packet. (Of course, there might have been client filtering of obviously misdirected packets.) So I now conclude that the protocol maybe does not hardwire client ports. Thank you for your additions also. ========= While the above is not directly on-topic for c.l.p, it does suggest possible design considerations for users of the socket module and packets built on top ;-). -- including Solipsis, which is such. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list