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- > >> >> > >> > > >> > > >> > > >> > > > > > > >
