[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] More commits (lots of windows fixes)

From: Kevin Fishburne
Subject: Re: [fluid-dev] More commits (lots of windows fixes)
Date: Tue, 13 Oct 2009 15:48:33 -0400
User-agent: Thunderbird (X11/20090817)

address@hidden wrote:
It would be nice if it was that simple.  The issue isn't with the client sending CRs (I added some code to handle that, basically just discards them), its with the server only sending LFs.  From what I read, the telnet protocol is supposed to be CR LF for the line terminators.  Unix is of course is just LF.  Not really an issue if someone is controlling FluidSynth from some other application via TCP, but if you want to telnet to that port, chances are the Telnet client might not work properly, unless it has support for different types of line endings.

If no one was relying on FluidSynth just sending LFs for its TCP/IP control shell, I would go ahead and switch the TCP/IP server output to CR LF.  Perhaps it is fine to just do so.  I doubt there are that many users of it and if there are, perhaps they don't depend on particular line endings.  Seems like telnet support would be more valuable.
I've used telnet for debugging an app that communicated with FluidSynth over a TCP socket and it was useful to me at least. I know next to nothing about telnet, but it seems plausible that the protocol may support some method of determining whether the client or server uses a CR/LF or just LF which could be implemented in the FluidSynth server and performed upon initial connection with a telnet client. It may already happen automatically when the connection is made, there might be a documented "preferred" method of doing it, or maybe some kind of hack has to be implemented. I found this:


which may be useless (sorry for my lack of knowledge). One of the options is "Output Carriage-Return Disposition", which sounds like it could be relevant. The best way to see if the CR/LF issue is actually an issue may just be to try a ton of telnet clients and see if any of them have a problem with the server's LF-only output. Wikipedia lists some telnet clients at the bottom of the article here:


I also found these, but they look mostly like Windows clients:


Kevin Fishburne
Eight Virtues
 (770) 853-6271

reply via email to

[Prev in Thread] Current Thread [Next in Thread]