From: Martin W. <meh...@we...> - 2004-08-18 10:17:42
|
Hey, first of all, thank you for your feedback. Just committed a new version of WNetwork. See below. Arne Rempke wrote: >> due to a severe bug in the WNetwork I released a new version that has >> some >> changes. The bug was that if more than one packet was sent to the >> server, for >> example, it received them as if they were one packet. > > > Well, uh, I don't think, that was a bug. It was. If I send a packet, I want to receive this packet and not all packets that were received since the last call. > >> Therefore WNetwork now > >> implements a packet separator (which is \n\r\t , but that's only >> internally >> important) and splits the received data into the original packets. >> Incomplete >> packets are stored and concantenated. > > > Ok, you add this seperator, but you don't mask this sequence. If a > client (or server) wants to send this sequence, it will never reach its > destination because it's filtered out and the data around this sequence > is splitted into two packets which can cause more problems than with out > this splitting. > Implemented masking and a variable separator. You have to call the constructor WNetwork(separator, separator_mask) or setSeparator() (same arguments) while separator is the desired separator (for craft \n, I think) and separator_mask is a 2-character-string whose first char is prepended and whose second one is appended for masking. This could be °°, for example. >> This involves changes in the interface of >> WNetwork: >> >> - ClientParse() and ServerParse() must take a packet (string) as >> second argument. This packet is now a reference. > That is quite ok, even without this new mechanism. Fine. > But... did you ever think of other clients? For example a telnet client > for testing would have no chance to send anything to the server (or do > you have a key on your keyboard that produces \n\r?). This is fixed with the new opportunity to set the separator to any desired value. Each application can decide whether it uses a telnet-compatible separator or not. > I think, your wnetwork class is the wrong place to put this seperating > feature. These seperating feature is part of the syntax of all data over > network. So the only instance that is allowed to produce this seperator > is the same that is responsible for the rest of the syntax - and that is > not your wrapping class. OK, now the instance that is responsible for the syntax is also able to set the separator. But I do not think that this separating is in a wrong place since (almost) all derived classes need it and therefore it would be nonsense that every derived class implements its own separating. WNetwork is not be intended for only being a wrapper class to SDL_net but also for adopting such things for derived classes so that those implementations are easier. > > In CNetwork, this is already implemented. The seperating character is a > simple \n, which is part of the syntax and which can be produced by > every telnet client. Yes, I knew that. But WNetwork is a separate library that develops further and this feature was needed for an other project of mine and a project of a friend. I'm sorry about that, but I think you can remove your implementation of separating. Imagine, SDL has a new feature which we implemented on our own before, we would also use the new SDL feature, wouldn't we? Kind regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |