From: Martin W. <meh...@we...> - 2004-08-17 08:34:01
Attachments:
signature.asc
|
Hey, 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. 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. This involves changes in the interface of WNetwork: - ClientParse() and ServerParse() must take a packet (string) as second argument. - The base class for the connections is now stored in wnetconnbase.hpp and should no longer be modified. The WServerConnection and WClientConnection classes are now declared in wnetconn.hpp as derived from WBaseConnection and custom elements should only be placed here. 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. |
From: Arne R. <arn...@gm...> - 2004-08-17 23:01:41
|
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. > 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. > This involves changes in the interface of > WNetwork: > > - ClientParse() and ServerParse() must take a packet (string) as second argument. That is quite ok, even without this new mechanism. 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?). 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. 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. cya arne |
From: Martin W. <meh...@we...> - 2004-08-18 10:17:42
Attachments:
signature.asc
|
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. |
From: Arne R. <arn...@gm...> - 2004-08-18 11:14:29
|
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 |
From: Martin W. <meh...@we...> - 2004-08-18 21:08:10
Attachments:
signature.asc
|
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. |
From: Arne R. <arn...@gm...> - 2004-08-19 10:15:01
|
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"? >>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. > Sending \n\n > Real sent is \n\n\n\n\n Real sent would be \n\n\n\n\n\0 > 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 (I think you did a \n too much, but that doesn't matter) > 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 >>>>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? 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. AFAIK SDL_net has no feature for this seperating, so that is a really new thing. cya arne |
From: Martin W. <meh...@we...> - 2004-08-19 13:43:23
Attachments:
signature.asc
|
Hey, Arne Rempke wrote: >>> 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 >>> 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? >> 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. > >> 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. >> [...] >> 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. > [...] 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. |
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 |
From: Martin W. <meh...@we...> - 2004-08-20 05:01:15
Attachments:
signature.asc
signature.asc
|
Hey, Arne Rempke wrote: >> [...] >> 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. OK, but the server knows that if it has the whole body sent it has to listen to new headers. > [...] > Ok, I just saw that the cvs implementation is another that you described > here, so that should work. Oh, dit I forget to mention that I implemented escaping? But that version had also a bug. So I implemented not only masking of \[separator] but of all \ . Here an example: Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\nfoo bar\n Parsed to: Packet 1: \nfoo bar With the old implementation the first \\n would not be recognized as separator but as masked separator. So with masking all \ : Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\\nfoo bar\n Parsed to: Packet 1: \ Packet 2: foo bar So this should work now at all events. > [...] > 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. ACK 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. |
From: Martin W. <meh...@we...> - 2004-08-20 07:21:10
Attachments:
signature.asc
|
Hey, Arne Rempke wrote: >> [...] >> 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. OK, but the server knows that if it has the whole body sent it has to listen to new headers. > [...] > Ok, I just saw that the cvs implementation is another that you described > here, so that should work. Oh, dit I forget to mention that I implemented escaping? But that version had also a bug. So I implemented not only masking of \[separator] but of all \ . Here an example: Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\nfoo bar\n Parsed to: Packet 1: \nfoo bar With the old implementation the first \\n would not be recognized as separator but as masked separator. So with masking all \ : Separator is n . Packet 1: \ Packet 2: foo bar Real sent: \\\nfoo bar\n Parsed to: Packet 1: \ Packet 2: foo bar So this should work now at all events. > [...] > 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. ACK 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. |