Solipsis: Python-powered Metaverse

[Terry Reedy]

>>On Wed, 11 May 2005 22:48:31 -0400, rumours say that "Terry Reedy"
>><tjreedy at udel.edu> 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 
> <tzot at sil-tec.gr> 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" <exarkun at divmod.com> wrote in message 
news:20050514001331.15422.1782566605.divmod.quotient.37593 at ohm...

>  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