Testing QuickServer from telnet and java.io (not nio) is ambiguous

[Jarl André Hübenthal]

I have checked the source, the line break separator is actually \r\n.
In 1.4.7. In older sources QS checks the system property for the OS
default. Not anymore. Only \r\n.

If I send from telnet "whatever\r\n\whateverelse\r\nsomeothertext"

This string is understood by QS as one command?? And I cannot parse a
multiline command in QS. It must be an unique line. Its how my QS
implementation should work.

How does telnet and QS work together? What does telnet adds in
windows? Why doesn't telnet successfully work with \r\n?

And why doesn't it work to send "whatever\r\n\whateverelse\r
\nsomeothertext\r\n" in a PrintWriter with its print method and NOT
the println?? In a java socket test (java.io)?
String s = "whatever"+System.getProperty("line.separator");
out.print(s);

Note: I do not want to use println method on printwriter. It should be
possible to not use println? To just append the \r\n myself?

I am on windows, so the default is \r\n. But I feel lost in the
testing as its impossible to send one string to the server and expect
it to wait for next line break before it understand it as a complete
line.

This sucks really bad. But I think its an integration problem.

[Jarl André Hübenthal]

Just to clarify Yes i have escaped back slashes and yada yada. This is a more complex problem.

[Jarl]

I am trying to work around the problem. Need to cache or append the incoming command to a property on the client data object and deside if an index exist for "\r\n" and then substring the cached command until this index and then process this result. The cached command will be from this index to the length of the string minus one. Thus making it possible to not care about how the client passes the data or how the server is configured to recieve. Making my application logic fully client and server agnostic. By all means if you have comments please say them out loud :) but this is my grand plan.

[Akshath]

If you have control of your client make sure you use some thing like BufferedOutputStream which is platform agnostic and add \r\n in code. 

But if you do not control your client and if the client can separate the commands using \r or \n or \r\n then its best you setup DataMode.IN to DataMode.BYTE and then use the logic as you described in your last post to breakup commands and process them.

(refer - http://code.google.com/p/quickserver/wiki/DevelopersGuideCh9 for more info on DataMode)

[Jarl]

Aight. Thank you Akshath. Even I knew about Byte mode before its nice to get kicked into using it. I configured the xml to use Byte for in, and made an abstract caching client command handler that implements ClientCommandHandler that makes sure to only call the actual protocol logic if it stumbles upon \r\n. I found out that supporting \r and \n was problematic because the clients only use \r\n and testing in telnet is acceptable for now :)

Case closed :)