| Blog |
|
| Releases |
| Can't Send Email? | |
|---|---|
|
Date: 9/5/2006 | Recently I've been talking with a customer who has this weird problem with sending email. The connection establishs ok and the normal SMTP session progresses up till the point where InScribe sends the end of message marker (\r\n.\r\n). At which point the server stops responding and the socket connection eventually times out. I got a hex dump back from the user that confirmes this.
I wasn't holding my breath on a solution for this as it sounds too weird to be a general problem with the software. However that all changed this morning when the mother of my children had the same issue. And when she has an email problem "It Better Get Fixed Right Now(TM)" ;) So I fire up the debugger and watch it do the whole send the email, send the end of email line and... hang... and time out... and return the blank error message. Nice. I consulted the oracle, and it informed me on Path MTU which I found interested. So the next hour was filled with frigging with every TCP/IP and MTU setting I could get me hands on. At one point setting the MTU to 1470 let some of the mail go through, but not all 11 messages, just some of them. So with 6 email still to send I called my cable tech support to see if they knew anything about this sort of error. Oh course they were dumb as nails and wouldn't let me speak to a real engineer about the network and server setup. However they did make me setup Outlook and sure enough that worked. *grumble* stupid Microsoft product actually working *grumble*, but it made me think about what differences there could be between Outlook and InScribe. In amongst all the other reading about MTU settings and email I ran across a little tid bit of information relating to sendmail (also used by my ISP Optus) it appears that in some network environments it matters which packet the end of mail ("\r\n.\r\n") line is in. i.e. if it's in it's own little packet things don't work. And of course I looked at the hex dump from InScribe and each line was it's own network "send". I would've thought that Windows implements Nagles algorithm and joins all those little packets up in the network stack. But just out of curiosity I quickly implemented a memory buffer for the outgoing email so that the entire message is assembled in memory and written to the socket in one system call. This of course works doesn't it. *grrrrr* So I guess I'm re-engineering the encoding of email so it goes through a memory buffer. However that may introduce new complexities that I hadn't had to deal with before, like whats a good buffer size (4k!)? And should I vary it when it doesn't work (no)? And what if it doesn't like that on '98 (who cares)? The list goes on and on, but then again, thats why I have "test" releases so that a change like this gets 3-6 months of field testing before going into a major stable release. Now you too know more than is healthy about TCP/IP. <nelson>haha</nelson> |
| (3) Comments | Add Comment | |
| Muhahaha | |
|---|---|
|
Date: 5/5/2006 | In the process of working on a cross platform Mutex written with inline assembly I had to peer into the bowels of gcc, cygwin and mingw to work out how to build threaded win32 apps with free software tools. So a number of pleasant things have occured in doing so.
Firstly I can now build Lgi applications with both cygwin AND mingw. Prior to today I didn't even know the different between cygwin and mingw. However I'm now in the "know" and have separate makefiles for each. Sweet. Secondly I discovered almost by accident how to craft makefiles that replicate the Visual C++ functionality to a 't'. Something that has eluded me for some 4 years now! Ever since I started development on Linux I've been trying to build a makefile system that works the same as the Visual C++ build system I am used to. And finally I've done it. The last thing I had to fix was the creation of output file directories. That particular feat while obvious for makefile gurus always was an annoying "hack" in my makefiles. I used to have a prereq on my final target rule that called the mkdir command: target : makeoutputfolder $(deps)
...link command...
makeoutputfolder :
mkdir $(outfolder)
But this had the unfortunate side effect of relinking the target every time, even if no dependencies had changed. So enter the solution: target : $(outfolder) $(deps)
...link command...
$(outfolder) :
mkdir $(outfolder)
I know it seems simple but, hey the documentation is er... rather obtuse. Other than that, I've given up on wildcard rules to build source and now I get LgiIde to generate all the deps and write out rules for every source file in the project. This is garrenteed to work and you can nail the right source file even when multiple different source files have the same name. Sometimes brute force is called for and when your as dumb as GNU make that is definately true. And before you have a go at me for not using %build tool Y%, I use make simply because it's on every system under the sun and it's nice to be able to unpack my source and just build it. It's a lowest common denomiator thing. Anyway, Lgi now supports mingw and cygwin. For all your licensing needs. |
| (1) Comment | Add Comment | |
| Opinion On Correct Behaviour | |
|---|---|
|
Date: 2/5/2006 | One user asked in the forum about a particular behaviour that shows up in Scribe when you receive email from someone with a Contact record. Currently the behaviour is that if the incomming email has no name in the from field, the name from the matching Contact record is inserted, otherwise the name from the headers is used. In fact I had to force the code to do that with a flag, because originally it didn't do that, instead it overwrote the name part of the from address with the name from the Contact record.
So both systems would appear to have some surface benifits. Firstly:
Neither of these are more correct than the other, or at least I can't decide which is better. In fact I could live quite happily with either. But maybe you dear reader have an opinion or something I havn't considered, maybe a reason one way or the other that would sway the argument? What I'm not willing to do is add another user visible option to let people frig with this. It's such a tiny part of the product I can't in good conscience add an option. There is nicely customizable and there is confusing. I would err on the side of nicely customizable and not add an option. Your thoughts? |
| (5) Comments | Add Comment | |
| Nine Frickin Months For This? | |
|---|---|
|
Date: 27/4/2006 | Yes Oh Yes, Nine long bloody months, a bout of RSI, periods of despair and madness, and not but least; completely crap documentation.
It doesn't DO anything yet, but omg I'm so proud! *gloating parent* Update: Getting more things working: 
|
| (2) Comments | Add Comment | |
| Known Feature Requests | |
|---|---|
|
Date: 19/4/2006 | I've been getting a bunch of similar feature requests for Scribe that I have already planned to implement for v1.89-test2 so I thought I'd just mention that bugzilla is the right place to check for existing feature requests and track their progress.
So the main points for the next release(s) are:
|
| (2) Comments | Add Comment | |
| Linux Builds | |
|---|---|
|
Date: 14/4/2006 | I've just spent most of the night checking out the codebase and building Lgi, LgiIde and i.File on linux. The xml project files are still very platform dependant so I'm making version for Linux and Cygwin and their associated Makefiles for the upcoming Lgi release. I'm also fixing various things that broke in the latest round of changes I'm doing for Scribe v1.89 test2. My aim is to do the next release of Scribe on Win32 and Linux at the same time. There are a bunch of Linux builds that need doing for other apps, i.Ftp, i.Hex and so on.
Currently I have Fedora 4 on my machine. And after booting between Windows and Fedora several times tonight it does highlight just how slow Linux's GUI is and also the boot/shutdown times. I guess you get what you pay for. All the classic Linux pain was still there. I had to learn how to use Yum... yet another annoying command line package utility (however it did, surprisingly, do what I asked of it). I couldn't play xvid movies out of the box. Mounting my windows drives was still all command line voodoo instead of some nice GUI tool. Ntfs drivers weren't installed by default. And the screen was shifted 16px off the right edge of the LCD. *sigh* Linux still sucks. I'm glad I have a Mac now. It makes me happy. I will however make some small token attempt to intergrate with Gnome for font settings and mime->application lookup. No promises though. (The current Lgi codebase looks for KDE settings) |
| (2) Comments | Add Comment | |