From: Martin W. <meh...@we...> - 2004-08-18 21:08:10
|
Hey, Arne Rempke wrote: >> [...] >> It was. If I send a packet, I want to receive this packet and not all >> packets >> that were received since the last call. > > With a call for send() you can't be sure that all passed data are sent > in exactly one packet. On a lower level (somewhere in you os' network > tcp-network-implementation), the data is buffered. So if you call send() > several times in a row, the data you passed in different calls is sent > together in one packet. Or if you call send() with a vera long string, > the data will be probably splitted into many packets. What you > implemented is no packet seperator, but a "function call seperator". OK, or you call it "logical packets" or so ;) >> [...] >> 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 changed now. separator_mask is abolished. Call simply WNetwork(separator) . > > That sounds better. But did you ever think of any protocols that do not > have a static seperator? A simple example is HTTP, where you have the > header which is seperated by \r\n, but then comes the body which has no > seperators. Logically all the data in the body belong together, but with > your seperating feature it would be splitted into several "commands", as > it was correctly done for the header. Yes, but HTTP need not to be able to receive data after the body since the connection ends then. And FTP has two data channels, one for the commands and one for the data since you can never be sure that a separator or a command is unique when transmitting files. > [...] > And another thing: Do you mask the seperator_mask? In your example with > \n as seperator and °° as seperator_mask, will °\n° be masked? Ok, it's > is not really supposable, that data will contain this (similar > possibility as \n\r\t), but we send binary files and I won't assure that > it's impossible. ACK > The better way for masking is not to add some > characters, but to dublicate all occurences of one masking character in > the content so that you can use combinations of one of this character, > as it is done with the backspace: \\ is the original \ and several > combinations like \n \r \t \" represent the data that you are not able > to express with a single char. You are right. Before, I already thought about duplicating the separator. But this also has disadvantages / bugs. For example: Separator is \n Sending \n\n Real sent is \n\n\n\n\n Received is \n\n as first packet. OK. That works I thought. But: Packet 1: test Packet 2: \n\n Sending packets Real sent and received is test\n\n\n\n\n\n Parsed to: Packet 1: test\n\n\n So this did not solve this issue. So I thought about implementing escaping and I did it. I've just committed the update to WNetwork. >>> 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. > > Yes, I think we should be (and stay) "telnet compatible" ;) > Sure, that's OK. I just didn't consider that in the first version of separating. >>> 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. > > Ok, I thought it was supposed to be only a wrapper since it had ne such > additional features till now. Of course, it had! What about connection management and the workaround since original calls to receiving are blocking? >>> 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? > > Probably, we would (in case it is stable and widely-used). Of course, and I think the separating with escaping now is stable ;) 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. |