Check out my latest product, BuildFactory
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/BLOG.php on line 170
Native Sockets with Mono
Warning: Parameter 1 to NP_Geshi::event_PreItem() expected to be a reference, value given in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/MANAGER.php on line 331
The number of powerful networking libraries available is quite astounding, but as a developer that works from his apartment writing software, I certainly don't want to re-implement those libraries, I just want to use them. As my previous posts might have made apparent, I do a good bit of work these days with Mono on both Mac OS X and Linux. "Who cares" right? On the one side of the table I have a set of powerful networking libraries, to do a wide variety of socket creation tasks, and on the other side I have a powerful runtime (Mono) that most of the code base utilizes. It is quite important to be able to make use of as much as possible of both sets of code, writing all my network code in C can lead to portability issues (and frustration), while re-implementing the network libraries in C# would crush any productive development.
A hybrid scenario is the best option given the current library I am working with, which performs some complex operations to provide NAT traversing sockets, etc. Thanks to some help from Alp Toker of NDesk, I was able to quickly implement some example code for this hybrid scenario. In this scenario, I need to call into my native library to create the socket, and then pass that socket back upwards to the C# code. While you cannot use a System.Net.Sockets.Socket object and some how lash it to a native socket file descriptor (similar to how CFString and NSString are toll-free bridged on Mac OS X), you can use Mono.Unix.UnixStream and instantiate the UnixStream object with an existing socket file descriptor. The UnixStream class is a subclass of System.IO.Stream, allowing you to read and write just like any other Stream object in C#, but the advantage of using UnixStream is that you bind it to natively created sockets, and perform I/O operations on that stream in your managed code.
In this brief little example (i.e. proof-of-concept) the libTestSocket library will open a socket to an echo server. The prototype for this native function is: int openEchoSocket(char *ipstr, int *sockfd);. By passing in an integer pointer, I can receive the return value as an indication of success (errno doesn't marshal too well from native->managed code) and still have the *sockfd value set to a valid file descriptor. Once the managed (C#) code has the valid file descriptor for the open socket, it can instantiate a UnixStream object, allowing the code thereafter to work with the native socket via UnixStream just like any other Stream object.
The code is not terribly complicated, but a good springboard for other developers and myself to make use of native networking libraries, while still keeping as much new (i.e. in development) code in C#.
Download/View this example
[tags: mono, sockets, network, unixstream]
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/ITEM.php on line 61
Write reply
This item is closed, it's not possible to add new comments to it or to vote on it