Life in a shell

bash$ tiagosh



Last months I’ve been working on porting libmsn to MSNP15. Yesterday I decided to talk with Mark Rowe about uploading the code to the mainstream development tree.

He agreed and added me as admin on libmsn project.

For those who want to test some of the library capabilities, there will be msntest command line program after the build.

I’ve been using msntest with my main msn passport (to receive oim’s and to talk when in invisible status) and everything is ok up to this moment. Anyway, more tests are needed.

My changes on libmsn are on sourceforge svn. There will be too much work until the first release, so, patches and discussion about the library layout are welcome.

Thank you all who have offered help on development and have commented on previous posts.

(svn co libmsn)

September 3, 2007 Posted by | libmsn | 8 Comments


Yet another foo bar song 2

August 22, 2007 Posted by | guitar, music | 1 Comment


Yet another foo bar song.

Sometimes I like to create my own songs.

August 17, 2007 Posted by | music | 4 Comments


First of all, the best cover ever:

No comments. It reminds me Anton Maiden. Don’t you know Anton Maiden? Shame on you.

If you are not a geek, you dont need to continue reading below 🙂

As in AC/DC song: It’s a long way if you wanna… do things in the right way.

libcurl is a great library which provides ways to open and manage sockets and http requests in a simple form. I was using it to help libmsn development, but as I intend to keep libmsn as independent as possible, I’ve decided to use openssl sockets instead of libcurl. The best part is now the code is prepared to handle non-block sockets, even when using ssl connections, which is, in my opinion, a big requirement to not block the whole library (as we can have many sockets alive at a time) when we are requesting something through SOAP, for example.

The code is broken and I’m working to fix it, but I must admit it is a very boring work.

July 28, 2007 Posted by | libmsn | 8 Comments

OIM? Yes!


Sunny Sunday: a good day to develop OIM (Offline Instant Messages) to libmsn.

Yes, now libmsn has full OIM support (receiving, sending and deleting).

I could write here all my feelings about the protocol, SOAP and XML parsing, but I’m trying to avoid this kind of discussion because I can discover very soon that it was really needed to do something I don’t know yet (btw, xml text inside another xml text node?? I think there are too many ways to not need to do that. I hope I’m wrong, really!).

Next step is try to finish Address Book management (add groups, add user, move user to group..). All these operations are made now through SOAP requests (oh my..!!). Wish me luck.

see ya!

July 16, 2007 Posted by | libmsn | 10 Comments

She wolf


some people asked me about posts involving music, because computing is a very boring subject. I agree with them, music is much more interesting than computing, so there goes she wolf (by megadeth) video played by me. I know it’s not equal to the original version, but this is how I like to play it =)

The sound quality is horrible because I used a standard PC microphone. I intend to improve this recording process next time. Probably you don’t know this song yet, but I can ensure you it is very cool. Enjoy.


July 8, 2007 Posted by | music | 4 Comments

libmsn news


yesterday my friend boiko encouraged me to contact Mark Howe, the original libmsn developer. I told him about the changes I made in libmsn, and I asked him his thoughts about forking libmsn. He told me it’s been 2 years the development is stopped, and if I want to maintain the code and revive the project I’m welcome. So, there is no need to fork libmsn so far.

Now it is time to face the worst part, which is code the library. 🙂

Today I dropped all the qt code I’ve been using to help on xml parsing. Instead of qt I’m using xmlParser, which is a tiny library I found when I was googling xml related subjects.

Probably next week I’ll have some news about the current development status.


July 6, 2007 Posted by | libmsn | 3 Comments

Network char device?


yesterday I decided to start playing with a capture card I have, but I faced a big problem: my PC is a laptop and the card is PCI bus. Since I don’t have PCI bus in my laptop, I couldn’t use it. The fastest solution was use my sister’s PC, which is a desktop one. This situation made me think about developing something to share the hardware through the network. For example: if NFS could export /dev directory, I would export it in my sister’s PC and mount it at /mnt/dev, and then access /mnt/dev/video0 in a native way. The problem is that video0 isn’t a normal file, it is a char device, and NFS does not support char device exports. If we think a little bit more, we will realize that the main problem consists on ioctl() function, which its use is very common on char devices. This function allows us communication with devices in a simple way by passing an ioctl type and some data or a pointer (most of times a pointer to structs) to the function. Each type of ioctl has different data types and sizes, so if we want to do it through the network, we need to map all the types and associate them to a fixed size (considering we cannot pass a raw pointer through the network). Anyway, it is possible to get the data size with _IOC_SIZE() function, for example:

#include <asm/ioctl.h>


where VIDIOC_G_MPEGCOMP is the ioctl type, and size will be the size of the data VIDIOC_G_MPEGCOMP requires.

I don’t know if I’ll have time and know-how to do the full development, so if you are able to do that and enjoy coding these crazy things, fell free to do it, and if I decide to start developing that I’ll post the progress here.

If you have more ideas or if I’m terrible wrong on my explanation, let me know.


July 3, 2007 Posted by | NCD | Leave a comment

libmsn (progress)

Hi all,

Here I am again to announce my latest progress on porting libmsn to MSNP15.

The file transfer is finally working (just receiving through server). I’ve tested receiving files from some different clients, like kopete, pidgin, amsn, Mercury (thanks to AsTrOdYuM) and the official MSN client. Up to now it seems OK. Next step is try to allow direct connection. One interesting thing is that the switchboard limits the transfer speed to 3k (average), and if you try to send many files at a time, the bandwidth will be shared between them. That’s why kopete file transfer is very slow. Kopete does not support direct connection. aMSN does support and pidgin does not even try to start direct connection negotiation.

I need to clean up the code yet. Many parts of the old MSN file transfer protocol are still in the code. I didn’t remove them to not break the building process.

During the tests I’ve found an aMSN bug. If you try to send many files at a time, probably the first one will be successfully completed and the other ones will fail. I thought it could be my fault, but the same does not occur in any other client, only in aMSN. Anyway aMSN has a good way to transfer files, testing the connectivity before inviting the other user. It tries direct connection first, if no response is received, then it sends through server. Probably when I start to change the file transfer code to send files too, I’ll use this approach.

see ya


July 1, 2007 Posted by | libmsn | 4 Comments

RNAT (Routable NAT)

Hi everybody,

Here I am again to show you another stuff which I’ve been spending some time to develop.  The RNAT, or Routable NAT.

This post is just an introduction to the RNAT project, since it is a very long subject.

Summarizing, I’ve started the RNAT development about one year ago. The main purpose was use it as my graduation final project. But after the presentation I realized that I could keep the project alive and turn it into a real and useful thing.

The real RNAT goal is to provide direct communication between hosts which are behind NAted networks by using two IP’s instead one. Like people say, one image is better than one thousand words:

[root@localhost ping]# ./ping
usage: ping [-LRdfnqrv] [-c count] [-i wait] [-l preload]
        [-p pattern] [-s packetsize] [-t ttl] [-I interface address]
        [-a RNAT Address] host
[root@localhost ping]# ./ping -a
PING ( 56 octets data
64 octets from - icmp_seq=0 ttl=63 time=96.9 ms
64 octets from - icmp_seq=1 ttl=63 time=52.7 ms
64 octets from - icmp_seq=2 ttl=63 time=49.8 ms
64 octets from - icmp_seq=3 ttl=63 time=41.9 ms

--- ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 41.9/60.3/96.9 ms
[root@localhost ping]#

It is just a small piece of the RNAT project. To get more information visit the official project site.


June 29, 2007 Posted by | RNAT | 1 Comment