From: Arne R. <arn...@gm...> - 2004-08-19 17:34:28
|
Hi, >>>>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. >>> >> >>No, that's not right. Have you ever heard of "keep-alive"? > > > What exactly is not right? I'm quite sure that the FTP description is correct. > References (German): [1], [2] > And sure I've heard of keep-alive on HTTP connections. But I do not know how it > exactly works. > > [1] http://www.uni-erfurt.de/rechenzentrum/anleitungen/ftp.html > [2] http://www.elektronik-kompendium.de/sites/net/0902241.htm FTP is correct, I never claimed it was wrong (you brought this example up). In HTTP/1.1 the client can add the header "Connection: Keep-alive". If the server agrees, it won't close the connection after the body but keeps it open for the next request. >>>>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 >> >>If you dublicate the orriginal occurence so that it is two bytes long, >>the seperator has to be the same length. For example \n is the mask, >>than \n\n means that it is a _real_ \n and for example \n\0 means that >>it is the end of our symbolic packet. > > > Didn't understand that. > > >>>Sending \n\n >>>Real sent is \n\n\n\n\n >> >>Real sent would be \n\n\n\n\n\0 >> > > > Are you sure that we get a \0? And what if a binary file contains \n\0? I think we will get a \0. AFAIK the SDL_net receive function adds a \0 to the received data, but the actual length is given to the send function with an extra parameter and is returned by the receive function. >>>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 >> >>Real sent and received would be test\n\0\n\n\n\n > > > Same as above. > > >>(I think you did a \n too much, but that doesn't matter) > > > No, I did not. You fogot the separator of the \n\n packet. Oh, that's right, and my correction was wrong. It would be test\n\0\n\n\n\n\n\0 >>>Parsed to: >>>Packet 1: test\n\n\n >> >> >>Would be parsed to (split at \n\0, then convert all \n\n into \n) >>Packet 1: test >>Packet 2: \n\n > > > See above. > > However, this discussion is somehow obsolete since now with the escaping I > explained it works fine. Ok, I just saw that the cvs implementation is another that you described here, so that should work. >>>[...] >>>Of course, it had! What about connection management and the workaround >>>since >>>original calls to receiving are blocking? >> >>That are all features which are not completely new, but which existed in >>another form. Even without wnetwork, you could establish several >>connections over SDL_net. And blocking in receiving is default, but >>SDL_net offered the possibility to change this. > > > No. In the docs nowhere was mentioned that you could get non-blocking calls for > single connections with SocketSets. They are even described to be used only for > multiple connections. I could say, that it was just not documented and perhaps also not easy to find in the code, but it was implemented by SDL_net. You only made your own functions to call the ones of SDL_net (which is of course not necessaryly a direct mapping of one function wnetwork to one function SDL_net). But it would probably be hairsplitting and it is not really important. cya arne |