Re: [craft-devel] New version of wnetwork.?pp

[Arne R. <arn...@gm...>]

Hi,

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

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

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

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. A similar thing is in craft during 
the syncronization: Files are passed, that contain newlines (binary 
files even more difficult characters), but all the lines of one file 
belong to one command.

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

>>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" ;)


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

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

cya arne