Hi Jeroen and pietry, TCP guarantees that the packets will be in the same order, that it will retransmit the lost packets and discard duplicates. You don't need to worry about all the above in your MINA based application because you are at a level above TCP, you are not implementing TCP, TCP does all this for you. You are too worried about how routing is done. You don't need to know this. TCP is a connection oriented protocol, if you are above the TCP layer then you deal with connections (sockets, etc), you shouldn't care what path a router chooses or other TCP guaranteed stuff.
On Dec 16, 2007 6:03 PM, Jeroen Brattinga <[EMAIL PROTECTED]> wrote: > You have to take these (strange) situations in consideration, and decide > what action to take. It could be that you discard a previous session if > you receive conflicting information. > > Remember that the 'conversations' (= the protocol communications) you > have will not always be ideal. Sometimes you get corrupt information, > sometimes the connection is dropped without any warning (or exit > message!). In these situations you can easily get conflicting messages. > > An example: someone connects to a server. The server receives a connect > message and keeps track of the client. It expects a disconnect message > when the client disconnects. But what if the client is terminated before > it can send this message? How long is the server going to wait for the > client? What happens if the client tries to reconnect ... the old > session is still active on the server... > > Oh, and packet routing is totally independent of both clients. Every > router along the way decides what path each packet is going to take. > This means that you are never sure about the route of each packet. In a > LAN situation, this is of course much easier (since the routing choices > are limited), but on the internet it's a whole different matter. > > A connection between two peers is often simplified as a straight line. > In reality that is always never the case; if you would draw the routes > each packet takes, it would look more like a mesh than a line. > > > Jeroen Brattinga > > > On Sun, 2007-12-16 at 07:40 -0800, pietry wrote: > > I'm implementing the ADC protocol. > > http://dcplusplus.sf.net/ADC.html > > > > The info received by any client is what happens to other client, which is > > independent to current client. > > In other words, the client receives for example notifications when somebody > > enters or exits. > > If somebody reconnects and the package of connection arrives before the one > > of exiting, then the client receives like : "another client with the same > > name connected, how is that possible now i have two of them " > > If a connection between two peers is made once, why package X would be > > routed through China and Y through Africa... > > > > > > > > Jeroen Brattinga wrote: > > > > > > What you're talking about takes place at a lower level. As an example, > > > say you are sending a 5Kb payload (a couple of lines of text, for > > > instance). > > > > > > This 5Kb is split up in packets; each one gets the right header and > > > checksum and is sent to their destination. There the TCP layer assembles > > > the separate packets, puts them in the right order and eventually passes > > > the data to the application. In the end you'll see the 5Kb; nicely > > > assembled in the proper order. > > > > > > This has nothing to do with the level you're talking about: the protocol > > > level. You have to do the order and status housekeeping for your > > > protocol. You could adding a unique ID to each message to do that. If > > > you can't see how that's possible, try sharing some of the details of > > > your protocol, maybe someone on this list has an idea. > > > > > > By the way, it might be a good idea to read up on the OSI model > > > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the > > > difference between the transport layer (TCP) and the application layer > > > (where your protocol functions). > > > > > > > > -snip- > > > >> >> > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > >
