05.30.08
Bugs bugs and more bugs
It seemed there was no stop to it! Thanks to my friend Jano, who’s using the SMTP component with SSL support via the new sessions, I got a flood of bugreports after 0.6.1 was released. But it didn’t end there, the bugs he reported lead to other bugs I found when testing the fixes!
All in all about 15 bugs got fixed, but lets get it over from the start.
First there was a problem with SMTP when SSL was turned on (either implicitly or via STARTTLS). There was a problem with sending bigger chunks of data, like mails with attachments. It turned out that due to an oversight on my side (albeit the OpenSSL docs aren’t exemplary either), I misunderstood the behavior of SSL_write(). It seems that when SSL_write() fails on non-blocking send with SSL_ERROR_WANT_WRITE error, the next call to the function MUST contain the exact same buffer pointer. This was a cheap check done by OpenSSL to ensure that the data you’re trying to send doesn’t change inbetween the two calls. Problem is, I was using ansistrings which got filled up (and thus relocated). This got promptly fixed by setting the SSL_CTX to ignore that check.
Another bug got reported right after I fixed this part. It seems that I completely forgot to handle the TLConnection.Session property in regards to visual assignment in Lazarus via OI. Not only did I make it so that it crashes on certain changes, I completely forgot to use the TComponent notification mechanism.
While fixing that extempore I found another, bigger one. My Sessions are NOT shared at all! I made a HUGE unforgivable logical oversight which caused each TLSession (and descendants) to only work for the last component they were assigned to. In other words, the sessions couldn’t be shared properly.
While fixing THAT bug, I found out that my TLSocket.Creator property isn’t delegated properly, resulting in wrong assignment. The idea behind .Creator is, that you will always know the highest-most protocol component by it, so you can go down the chain. For example, TLFtp uses TLtcp which makes the TLSockets. On your events you get the aSocket: TLSocket as argument, and if you ask it for it’s .Creator, you should get the FTP component.
So I fixed these three huge oversights, but the finish line was still far away!
I got another bugreport from my friend about SMTP. He wanted to automate mail sending, more precisely send a SMS (via smtp) and a normal e-mail automatically. Since he needed it inside a visual application he followed my visual SMTP example and automated the process. He found out that if the SMTP.PipeLine was turned off (default, means “emulate pipelining on server”), his commands got “stuck” after the first 2.
This was another logical bug on my part. In SMTP and FTP, I have a state-machine which takes care of the various states in these protocols. It is implemented as a stack, I push the status in, wait for server response and then remove it. The problem was, that I reported success or failure via OnSuccess/OnFailure BEFORE I removed the given status from the stack. If you sent another command inside OnSuccess/OnFailure event handler, the command would get pushed on the stack, but when the execution returned to me, removed again. This basically causes a de-sync, because now SMTP/FTP is waiting for a command not issued.
There was one additional bug fixed during the marathon, not reported but noticed while I tested SSL on both SMTP and HTTP examples. In HTTP I noticed that in Windows, HTTPS download of a page failed, it just got stuck in the middle. I was quite sure it had to do with the windows gui eventer I use in case of visual lNet, because it worked in Linux, and the console version worked in Windows too. Since I use WSAAsyncSelect for the visual eventer core functionality, I decided to properly study it’s documentation on MSDN and see what’s up. It hit me when I read about the “re-enabling” functions. You see, in WSAAsyncSelect, you tell windows “watch this socket for event xxx”. When the given event happens (like “can read”), you get a windows message. The problem is, that after it’s reported, WSAAsyncSelect DOESN’T watch for the event anymore, until you call a “re-enabling” function. However with SSL_read, it’s a problem, because it doesn’t call recv() always, it sometimes just processess the rest of its internal buffers. This causes a de-sync of the event flip-flop. I fixed it by a little hack, since I want the event to always be reported if there’s anything in the buffer, I did a recv() with MSG_PEEK after each read event reported. This ensures that WSAAsyncSelect watches for reads again without removing anything from the recv buffer.
So.. that’s about it. There were some minor example fixes along the way but nothing to write about. I hope this doesn’t undermine lNet’s viability for you. I’d also like to thank my friend Jano Kolesár for all the testing on SMTP.
05.18.08
WinCE OpenSSL mixup
It seems I made another mistake 
WinCE fpc 2.2.0 doesn’t currently contain an OpenSSL.pas file. It is present physically but not compiled for that platform. I was only testing things on the fixes (fpc 2.2.1) branch and didn’t realize this. The problem is that lNet requires OpenSSL.pas since 0.6.0 (it doesn’t however need openSSL library to be present unless you use SSL stuff).
I’ll fix this by adding OpenSSL.pas into lNet itself until at least fpc 2.4.0 is out, but until then, please follow the workaround I posted in news section.
04.26.08
A bit of a switch
It seems that while SSL made it into 0.6.0 (albeit in a rather bumpy way), Qt4 support got postponed. The good news is that at least one of them made it though.
0.6 saw an addition of sessions and some minor redesigns. All in all I feel good about this release. Apart from the logical problem with SSLSession, all seems to be working ok.
Another thing some of you might have noticed is that the new release didn’t change sending in any way. Indeed, in the past I had it planned to change sending in basic TLSocket to be more “user friendly” by making it buffered and automatic on TCP connections. In other words, if you send something on TCP you no longer have to care about how big it is and if it made it in one send command. The idea to do this was scrapped however, mostly because lNet still is lightweight, and it was decided to stay so. The original design made this change a bit more complicated, and I decided (after some persuation by Micha) that it’s better to leave things as is.
If someone needs to simplify sending of bigger chunks of data, they can always inherit from TLTcp and TL[SSL]Socket and change how sending works. But the basic building blocks of lNet will remain as they are.
01.11.08
Holidays delay
I must admit that I was a bit delayed by the holidays. First a one week LAN-party and then I got some sort of “winter” influenza, nothing serious but very bothersome. To top that off I still have to finish both my payed work assignment and school assignment in the coming days so in all honesty I didn’t work on lNet all that much. I did some minor changes, prepared packages for 0.6 and did some early fixes on the higher protocols after the send change. What still remains is the Qt4 visual support and at least some sort of SSL work (doesn’t mean it will be included right in 0.6.0 tho).
I’m not sure when 0.6 will hit the streets since my finals start 18. January and continue until 31. unless I fail some, in which case it would go on even longer. I hope to have released lNet shortly after this circus ends 
11.06.07
0.6 incomming
I have started work on the first fundamental changes towards 0.6 release. Namely I have implemented the “easy sending for TCP” which enables users to just send data and not care anymore (more or less). Up until now you had to do a tedious loop with OnCanSend sending “trick” and in all honesty it wasn’t exactly optimal (usability wise, speed doesn’t change).
Now I need to test this on basic TCP server/client and start fixing higher protocols which use TCP. Old functionality will be still possible if you specify the old TLSocket as the SocketClass property for the TCP object. This means that even inherited TLSockets will work “old style” and of course analogically, new TLSocketTCP will also allow descendants.
Once this is done and FTP and HTTP works reliably again, I’ll start to hack on SSL. If everything goes well I might even manage a QT and Carbon Lazarus integration (will require probably Lazarus 0.9.26 or even greater depending on when my changes get in).
All in all 0.6 looks pretty promising.
On a side note I have entered benchmarking of the various event models (select, epoll etc.) as my research project at the university so we might get some tangible comparisons soon
09.16.07
SMTP bugs
Trom has came into #lnet recenently and told me of some odd problems with HTTP and SMTP he had. The HTTP problem is most probably a GTK bug in TMemo, but the SMTP problem turned out to be a bug in lNet regarding RFC compliance.
I had 2 problems.
1. The DATA command is defined by RFC to be “DATA <CRLF>” and one should wait for reply from the server before commencing the send of actual data. I had not only omitted the wait, but also used the format “DATA <first line of data><CRLF>”. Oddly enough some servers have accepted this happily. This has been fixed in 0.5.8 release.
2. The line length I used in SMTP was 74. This is a very outdated number, and since a long time ago, 1000 chars per line are allowed. There was also a bug in the line breaking algorithm which could cause data corruption on bigger attachments. I fixed both of these issues in 0.5.8 release.
I must say that I was honestly skeptical about Trom’s reports because SMTP worked reliably for most people until now. It just proves that skepticism isn’t always the best course of action.
Hopefully 0.5.8 is the last of 0.5 line and 0.6 will be released soon. More on that later…
08.12.07
Blog start
I have just been inspired by Vincent’s blog to start a blog of mine own so here it is.
lNet is progressing nicely. Version 0.5.8 will hopefully be out soon and I hope it will be the last of the 0.5.x line. There are some plans for simplifying of the sending in TCP sockets which will slightly change semantics and warrant a 0.6 release.
If everything goes ok the next major release will also contain OpenSSL support and possibly also some additional protocol implementation.
