XPost: alt.winsock.programming, comp.arch, comp.dcom.lans.ethernet   
   XPost: sci.crypt   
   From: grahn+nntp@snipabacken.se   
      
   ["Followup-To:" header set to comp.protocols.tcp-ip.]   
      
   On Thu, 2010-09-09, Skybuck Flying wrote:   
   >   
   > "Ken Hagan"  wrote in message   
   > news:op.virckiqvss38k4@khagan.ttx...   
   >> On Thu, 09 Sep 2010 06:25:49 +0100, Skybuck Flying   
   >>  wrote:   
   >>   
   >>> The ip.source is translated into something else/arbitrary along the   
   >>> path's routers to it's destination.   
   >>   
   >> There's your mistake. You cannot talk about "the" path from source to   
   >> destination because in general there are multiple paths and different   
   >> packets in the same TCP flow might travel by different routes.   
   >   
   > While I did not think of multiple paths the idea would still work.   
   >   
   > The packets from a flow could be routed among different paths and get their   
   > own treatment.   
   >   
   > The end result would be that the destination/end point gets packets from it   
   > would seem   
   > different sources, for a tcp protocol this could be a problem.   
      
   It would break TCP.   
      
   > But for for example P2P application like BitTorrent it doesn't really matter   
   > where a packet came from.   
   > Especially for the UDP variant I would presume ;)   
      
   UDP-based protocols keep state too, and are just as picky about where   
   the datagram came from as TCP. You cannot expect every datagram to   
   contain full context, so the application protocol uses the source   
   address:port (and maybe destination too) as a key to lookup state for   
   the "conversation".   
      
   Also, please don't cross-post to irrelevant groups. This has nothing   
   to do with Winsock programming, crypto or Ethernet.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)