Remote Backups

We found a very interesting supplier of a service provider oriented backup system. I will try to implement it on some of our customers during this week.

There seams to be a lack of these products. Especially at the mid segment...

A week full of discussions

I have had a week full of very interesting discussions.

There has been everything from finalizing business meetings to deep discussions regarding future cooperation opportunities.

I visited Finland again. It has been a while and it was nice to see Helsinki, even though it was a very short sight while driving out to the Finish Expo Center in Pasila. Later on, after attending a few inspiring meetings we drove to Turku. I have never seen Turku before and I had the chance to tour it briefly after our business meetings were over the following day. I must say I liked it!

Our sales manager is picking up speed. It will be very interesting to see her work in the upcoming weeks! We have high hopes for her...

We are looking for sales trainees and IT technicians as well so if you happen to be Swedish and English speaking person living in Stockholm and looking for a job, let us know!


Cheers

Sending non ASCII byte characters with Java

I recently wrote a short piece about a simple Telnet implementation. I got it all working...until I moved the code to a Solaris machine. Then it stopped working.

It turned out that the problem was the platforms' default charsets.

So, if you plan to send byte long control characters over TCP with Java. If you also choose to use the character based print and read methods from the Writer and Reader classes, as opposed to the byte based write and read methods. Then you should seriously consider manually setting the charset.

For example, in the case of a BufferedReader:


BufferedReader br = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
Charset.forName("ISO-8859-1")));


Over and out for now then.

Simple Telnet Client implementation

Some background
I recently had to implement a software which needed to communicate with a system over Telnet.

My first thought was "Well that's easy, I just send and receive raw TCP". In the end things actually turned out to be almost that simple. However, "just raw TCP" didn't get me all the way.

In fact, it didn't even get me started. In order to talk with most Telnet hosts, you must first negotiate some capabilities. If you don't the host will think you are too stuck up to talk to. For you guys who already know this, the following post will be way below your level.

The key to solve the problem was to look the RFC up, as usual. The RFC you should be looking for is RFC 854.

I do not intend this post to be a pedagogic Tutorial or Howto. I am simply documenting the conclusions drawn from my own first time implementation of a Telnet Client.


The idea of Telnet
The basis of the Telnet protocol is that it should as if you where sending raw TCP. At least as long as you only send ASCII.

In order to negotiate about terminal capabilities, local echo and such, there is a set of codes outside the ASCII table range in order to help you along.

The idea is for the host to not only respond with ASCII output, but to be able to format it in a nice human readable way as well. To do this, the host needs to know what tricks the terminal can do.

For me, writing an automated software, taking this into consideration was a necessary evil.


Negotiation Flow
Telnet negotiations consists of command pairs. There are the positive commands:

• DO


• WILL

... and the negative...

• DON'T


• WON'T

This means for example that in order to request a capability the host or the client sends DO. In order to confirm, the other side sends WILL. There are a few considerations that are mentioned in the RFC to point out:

• Both parties send an identical request simultanously, each party should consider the other's request as an acknoledgement.


• Parties may only request a change in option status.


• A request to set the party in a mode it is already in shouldn't be answered at all.


• Parties may only request a change in option status.

These pointers are really really important! If you don't consider it in your implementation, you might end up with very interesting loops...

Note: Even though most negotiations are handled in the beginning of a session. There might be new requests sent at any time during a session. If you are writing a user interactive client, these requests are important. However, if you are writing an automated software you just need to know what codes to filter once you are done with the initial chit-chat.


So how do I recognize a command?
A command is always preceeded by the IAC character (see RFC 854). After that, one or more characters will follow in order to describe the command.

One thing to remember is the SB and SE characters. They are there in order for one party to request additional modes. Common modes are for example terminal color capabilities and terminal geometry. When you trace a SB character from the host, I suggest you simply google the characters sent in the sequence in order to find the corresponding specifications.



Implementation tips
So, the straight forward way to handle this is to write a class to wrap around your standard client Socket implementation.

Let your little wrapper catch the IAC codes and handle the negotiations, let the rest pass through. Simple as that.

Our first fulltimer

A while ago, we hired hour first part time technician. That was fun. However, today we hired our first full time developer. That was great!

Of course, neither me or my daughter have anything to do with this post.

Long time no see

Hey guys, I'm back. :)

The past months has been quite intense, although fun as well. We are now running a company called Pale Blue AB. It is situated in the Stockholm area and focus on IT Service and consultancy based software development.

It is going well. We are building an growing business network and (believe it or not) we are actually getting customers! :-)

With our broad competence, we can probably help you with whatever IT-related problem you need solved. So, now you know where to find us.



At home, things are running really good as well! Our daughter, Tilde, was born on December 13th and is now a very active and happy 5 months old baby. Becoming a parent is rewarding. If you haven't, I can recommend trying it.

Going back to Stockholm

So, it is now time to leave Portugal and head back for Stockholm. We plan to pack the car and leave in the next few days.

Both Marika and I will miss the PDM&FC folks here in Lisbon but we will keep in touch. Specially since we will continue working for PDM&FC while in Stockholm.

In parallell to this, I, Miguel (Founder and CEO of PDM&FC) and two more friends have started a new Swedish company called Pale Blue Dot (Website coming up soon).

So, I will definately be busy enough. :)

Winds picking up around ICANN

Carl Bildt wrote this entry in his blog about the struggles around taking over the political control of the Internet. Even though ICANN doesn't control ALL INTERNET, I agree with Carl Bildt's concern about the recent maneuver from the European Union.


...all in all. Get a Grip EU! Yes, sure the US is acting like a retarded teenager who doesn't want to loose his toys. They always do when it comes to international politics. This doesn't mean that you, EU, should sink to the same level. Actually this time you have gone way below.