by Bogdan Varlamov (a.k.a. Phantom Stranger)
I recently ran into an issue with an application that was not detecting a physical network problem and was consequently losing data while attempting to write it to the socket.
I know what you are thinking. Sounds like poor programming; surely the .NET Socket class has a clean and Object Oriented way of handling network failures.
That is what I thought at first. The .NET Framework is filled with tons of goodies--namespaces with classes that make coding life easier. I am usually fairly satisfied with what is available in .NET (especially in .NET 3.5), but when it comes to the System.Net.Sockets namespace, there is just more to be desired.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I've been doing a lot of work with .NET Sockets lately, and I will be posting more articles discussing what I've been working on in greater detail. In this article, I want to talk about the concept of reading a Socket asynchronously, raising events to notify your application when bytes are received, and minimizing the number of times the callback method is processed.
If you are familiar with .NET Sockets you might already know that there are asynchronous methods to receive bytes from Sockets (Microsoft has an Asynchronous Server Socket Example available if you are interested in seeing code for doing this).
In the above code sample, a StateObject class that contains a byte buffer with a static size is passed around. When the asynchronous socket read happens, incoming bytes are stored into this buffer and then passed back to the receive callback method. This example works fine, but I think there are some optimizations that can be applied.
Would you like to know more?
- Published:October 6th, 2008
- Comments:No Comment
- Category:PHP, XML
-
Share / Bookmark
One of my current clients has an old FoxPro (old as in created in '97 and upgraded in '99) database application that the users can't stand. It frequently crashes and it's all too easy to lose valuable data after a lengthy data entry session (just by clicking the sadly misnamed Save button). We are porting them over to a LAMP-based web application. One of the early tasks in this project is to analyze their existing database structure. This application involves hundreds of FoxPro DBF files which are tables (data and schema) that reside in various child directories.
My initial approach (following the KISS principle) was to inspect some of these files and see what's in 'em and how to get the schema out of 'em. I downloaded a trial version of DBF Viewer 2000 and it's a fine tool. I was able to view the data and the schema and, using SnagIt, I captured the text and pasted the values to an Excel spreadsheet. But purely manual approach would take way too long for me. Time to whip out a quick script. The problem: .NET or PHP or other? I'm a recovering .NET dev working on PHP apps. I surprised myself by deciding to go for the PHP option. And I'm glad I did. Here's how I was able to create an Excel spreadsheet with hundreds of worksheets in PHP.
Would you like to know more?
