So I created my own minimal Telnet client for sending commands to some controller that I have in my house and I was having issues with the server sending back chunked data that was separated into random lines.

I realized after some time that the server was sending back an additional '\x0D\x0A' to every chunk, and after trimming that off the output was consistently "normal" every time.

This can be heavily expanded upon and probably improved, but here's what I had written in the last 5 mins so far:

I wasn't entirely sure what the best way would be but after I send the BYE command, this particular server sends back the "Disconnecting. Bye." string so I just used that because I didn't want it part of the output, and I also didn't want the generic "SERVER_NAME>" to show before each command so I used some very basic regex which again I wasn't sure of, but it works for my particular project.

Thought someone might find this useful though :).

NOTE: Yes I know I could have used "\r\n" I just wanted it to stick out a bit more so I used hex instead to help me understand that it's required. I should have had a separate function which always appends this to the command string, but this is just a basic PoC for me so far until I had it fully working. Soon I will work on refactoring everything.

I'd usually tell a person writing their own telnet class to "just use PuTTY", but where's the fun in that? We (as coders) may not have to reinvent the wheel, but it's so much fun doing it! And you learn so much in the process, too.

Don't think I'll have or want to use telnet for anything - unless the WiFi lamps I plan on getting eventually are driven by telnet commands - but I still enjoyed reading through the code. I found it interesting that you used for(;;) instead of while(true) or a similar form. Since you simply used a break the result would be the same, right? Any particular reason for that?

Looking forward to being able to code more myself, I noticed I really miss doing it...

Well the reason I wrote my own is because I already have UDP broadcast and SSDP as well as USB discovery soon for the devices I'm interested in on my network. They use telnet for command-line interaction however, so the idea was to discover a certain device, connect to it via telnet and issue a set of commands all from the same program automatically.

The only WiFi lights I've dealt with are Philips Hue, and those use TCP rather than UDP and they use standard port 80 for communication with a REST API hosted on the bridge which is attached to the network. The bridge communicates with the lights for you via ZigBee.

And the reason I use for(;;) is partially old practice. It's preferred in C/C++ but also more optimized than while(true) in C# code that is not optimized. NOTE: By default the debug configuration disables optimization and the release configuration enables it. for(;;) from what I recall is the same as a simple non-conditional jump whether it's optimized or not. It also has more verbosity to me because of my style, that it's intended to be an infinite loop for the most part. I don't abuse while() loops to do this and reserve them for proper conditions/expressions that can be manipulated because that's what they are really intended for in my opinion.

edit: I guess initially I didn't have that null check, but I suppose now it should be changed to:

Code:

while (_tcpStream != null)

I think the reason for the broadcast was for legacy device support lol. Because I have no idea why anyone would use broadcast messages for device discovery, that's what multicast is for, particularly SSDP in a lot of cases. Less network bandwidth too, and there's lots of support built in for avoiding or allowing multicast loopback with sockets. You can't do that with broadcast as far as I know, so you'll still receive the message that you sent, and you have to filter it manually.

As a sidenote: VERY lame that the development for their stuff requires VS 2008, and in addition to that, they use the .NET compact framework (v 3.5), and they also don't let you do much with the framework directly, you have to use their limited wrapper around an already minimalistic framework, and they'll sandbox you away from using sockets directly. Sad thing is that their library would have a lot of memory leaks it if weren't for the GC lol. I found out today that they don't give you a UDPClient class in their wrapper either so that throws any implementation of SSDP out the window.

I was trying to use their library for implementing SSDP today and that's what I concluded.

Ah, that sounds like a fun project! May I ask what kind of devices you're using?

I also thought about your change there but forgot about it while typing (was pretty late for me), using while (_tcpStream != null) instead of if (_tcpStream == null) break; seems reasonable for readability if nothing else. One of my programming teachers always said if we used breaks in our code we'd lose points in tests for bad coding style. I don't entirely agree on that and do use them when I see fit, but in this case... Yeah, I think it's better :P
Didn't know about how for(;;) and while(true) behave though, but it makes sense what you're saying. Never learned these things in school...

About the Philips Hue, I don't know if I'm going for them. Heard they're pretty expensive, but then again I didn't look for alternatives yet. We'll see! Need an apartment to live in first ;)

The limitations sound pretty rough, hope you can figure something out somehow! Good luck!

This telnet implementation actually came in handy for troubleshooting I did today.

The devices are Crestron network devices. Embedded systems.

The problem with standards like *that* is the fact that if you think that way 100% of the time then you're more worried about conforming to some subjective coding standard rather than writing maintainable and in some cases readable code. I would never agree with a professor telling me that it's bad practice. Features of a language are there for a reason, you use whatever you see as most fitting if you have a reason behind it. In lots of cases the output will probably be the same due to code optimization too so why would I care that I'm using a break statement over some odd flow that I may not be used to?

Philips hue is expensive because the device itself is a smart device, but for that reason, and because it's an LED bulb, it's going to last you a very long time, and it doesn't require you to do any damage to existing infrastructure because it's all wireless.

There's people that say goto's are bad, but if you use them wisely they are a tool to be used IMO. In C for instance, lots of code written by the guys who initially wrote for Linux use goto's for a readable and clean way of cleaning up; freeing data from the heap, releasing locks, etc... If you had a bunch of nested if statements and conditions instead, lots of that code would be scattered and nested.

To be honest, most profs have never been in the real world like most other programmers from what I have known. This means that they teach the concepts, and most of what they teach is based on the textbook rules, concepts, and theories, not real world learned practices that work based on statistics or solutions derived from certain coding disasters. That's dangerous IMO.

Engineers are in the same boat. I've heard stories of new up and coming Engineers starting their first job, and not knowing really what to do because they learn the concepts but don't understand how to put them into practice.

See I already tried to re-write this using a smaller .NET micro framework, and the things that I knew I was missing out on this raw TCP telnet client implementation had affected my ability to write a telnet client for communicating with a server for controlling it.

Quote:A standard Telnet client would be able to negotiate the session options without problem, but several third-party controllers do not implement a Telnet client by default. Instead, they implement control over TCP/IP using what’s commonly known as a ‘RAW’ connection. If the Control System does not respond to the Telnet session options negotiations, the session will not go ahead. As such, the control system will have to be programmed to negotiate the Telnet options with Tesira’s Telnet server.

So now I've written code that will parse and respond to the negotiation as such, and hopefully it'll work in the test environment this coming Monday. :)