DarkSocket - raw networking sockets, like MooSock

Please login to see this link.
DarkSocket is a powerful socket extension, capable of creating sockets in several ways.
The basic functionality has a choice of TCP, UDP and ICMP (pinging), which gives a total of 6 methods of using the object (server & client).
Or for advanced users, use different actions, and gain access to over ten thousand possible methods of using the object.
A total of 28 protocols, 29 different address families, and 5 different socket types are supported.
The extension is multithreaded so your program will not halt during any operations - you can have up to 256 sockets open at once, if your hardware is capable enough.

Download includes a HTTP connecting example.

Conditions:
On error:
When an error occurs in the extension.
On new status:
(For debug) When the extension has a new status.
Client returned message: (number Socket ID (use -1 for any socket))
When a client socket has received a message, this condition will trigger. The message can be accessed with LastMessageText$().
On socket done:
When a socket has finished, this condition should trigger.*

Actions:
Client > Basic initialise: (string Hostname, number Port, string Protocol, string Initial text)
The first parameter (Hostname) is the hostname to connect to, the second (Port) is the port to connect on, the third (Protocol) is the protocol to use. The basic mode is limited to "TCP", "UDP", and "ICMP". Once a connection has been established, the text in the fourth parameter (Initial text) is sent to the server.
Client > Advanced initialise: (string Hostname, number Port, string Protocol, string Address family, string Socket type, string Initial text)
Advanced: Do not use unless you know what you are doing.
The first parameter (Hostname) is the hostname to connect to, the second (Port) is the port to connect on, the third (Protocol) is the protocol to use (IPPROTO_***).
The fourth parameter is the address family (AF_***), and the fifth is the socket type (SOCK_***).
Once a connection has been established, the text in the final parameter (Initial text) is sent to the server.
Some values for the parameters are given Please login to see this link..
Client > Shutdown socket: (number Socket ID)
The parameter (Socket ID) contains the socket ID that is to be shut down.
Client > Go independent: (number Socket ID)
The parameter (Socket ID) contains the socket ID that should go independent. This means it no longer scans for messages from MMF2, and should not be used under normal circumstances.
Client > Set to receive only: (number Socket ID)
The parameter (Socket ID) contains the socket ID that should be set to receive-only. This shuts down the sending part of the socket, generally not used.
Client > Send text to server: (number Socket ID, string Text to send)
The first parameter (Socket ID) contains the socket ID that will send the message, the second (Text to send) contains the text to be sent.
Client > Link socket output to file: (number Socket ID, string File to link to)
The first parameter (Socket ID) contains the socket ID that will send the message, the second (File to link to) contains the file that the message should be appended to. This is useful for keeping a log. To undo, see the next action
Client > Unlink socket output: (number Socket ID)
The first parameter (Socket ID) contains the socket ID that should disable linking. It undos the previous action.
Client > MMF2 reports on/off: (number Socket ID, bool On or off)
The first parameter (Socket ID) contains the socket ID that will have the reports (messages received conditions) disabled or enabled. The second parameter should be 1 or 0, and sets whether the socket reporting is enabled or disabled. If disabled, "Client > On received message" condition will not be ran by the socket. This will report an warning (but not an error) if there is no file linked to the socket, as that means you will have no idea what the socket is doing.

The server actions have not been implemented.

Expressions:
Error$ (bool Clear)
The errors (if any) that have been generated. Use 1 for the parameter (Clear) to erase the current errors. Use with On Error condition.
Report$ (bool Clear)
The reports (if any) that have been generated. Use 1 for the parameter (Clear) to erase the current reports. Use with On Report condition.
LastMessageSocketID
The Socket ID that received a message. Use with Client > On message condition.
LastMessageText$
The last message that was received. Use with Client > On message condition.
LastMessageAddress
The memory address of the last message that was received. Use with Client > On message condition.
LastMessageSize
The size of the last message that was received, in bytes. Use with Client > On message condition.
NewSocketID
The most recently started socket's ID.
GetSocketIDForLastEvent
The socket ID that ran the "Socket done" condition.

Please note this isn't the exact format that the final version will take. Any deprecated actions/conditions/expressions will run a popup message requesting you replace them.

Click the title of the object to download.

Pre v1.1 update:
• CPU usage improved.
• Bug that caused some connections to not report messages fixed.
• Example moved from requesting Google's icon to Google's index page.

Just a note that there has been issues loading this object under Windows 7. I don't possess the knowledge to isolate it so I would appreciate it if someone could run Depends.exe on the extension and isolate missing dependencies.

Next update will include servers, and from the look of things I'm going to have to extend the object considerably more to allow IPv6, since bind() is kicking up a fuss.

Quote from Jamie

The runtime is not thread safe, so short of having some kind of custom message queue (as earlier Lacewing builds did), I'm wondering how you're managing to safely spin off blocking I/O without causing big performance or stability issues.

Thanks for the input, Jamie, I appreciate it
Yep, DarkSocket uses two message queues (MMF2->threads and threads->MMF2) and a Extension:: read/write lock for threadsafe operations.

I'm not sure about the I/O blocking problems, I have the extension use the ioctlsocket() function to set all the sockets to non-blocking by default. All testing has been on the main 3 protocols, (TCP, UDP, ICMP) thus far, and no error thrown that non-blocking isn't permitted. However, before I made the change to have the ioctlsocket() call the extension did abuse the CPU usage.

Quote from Jamie

The correct way to do networking with MMF is through the use of Please login to see this link.. Anything else (especially multithreading) is likely to suffer badly in terms of performance, stability or, most likely, both.

I'll look into moving to I/O Completion Ports, but workload has gone high again, so a release will not be for a while.
Also, it's not clear whether that has limitations on the choice of protocols the sockets can use, and it seems to be relatively undocumented.

For the update-watchers:
Next update includes the ability to create servers, and the ability to form packets. An ICMP example will be included.
Due to the new packet-forming functionality, the extension has moved from using string variables for packets to raw memory copying. I have to double-check all the memory-related functions before I release, although that doesn't meant there won't be any memory leaks.

Excellent, I'll see about implementing it

First priority I have is ensuring the three main protocols are working out.
• UDP - untested
• TCP - working fine
• ICMP - sending works fine, receiving needs work
• Advanced protocols - not tested
I've been attempting to create a checksum generator for ICMP (pinging), but so far results have proved unsuccessful. I've successfully tested Ping Request and the network connection received a Ping Reply in return. However the object is not receiving those, so I'm going to be developing on that. IPv6 support has been improved further.

ICMP checksum was sorted out today, tests are continuing into ICMP. The next update also includes server capability.

Currently I can't work on any of my extensions until the EDIF bug is fixed.
Please login to see this link.
ICMP packets have the format:
IP header
ICMP header
data
Since DarkSocket writes only the IP header of a packet for ICMP, the MMF2 coder must write the ICMP header, so you can use any functionality of ICMP with DarkSocket. You don't have to worry about generating the ICMP checksum part of the ICMP header yourself, since I added an expression that will generate it for you.

I shouldn't expect so, Flash does limit heavily - doesn't even support UDP - so most features will be missing.
In addition, Flash doesn't support threads, so I can't make a multi-threaded extension in AS3.

Quote

Real-Time Media Flow Protocol (RTMFP) is a new communications protocol introduced in Flash Player 10 and also available in AIR 1.5. One of its major differentiators from Real-Time Messaging Protocol (RTMP), which is based on the Transmission Control Protocol (TCP) and exclusively used in previous versions of Flash Player, is that RTMFP is built on User Datagram Protocol (UDP).

Please login to see this link.
Adobe Flash's RTMFP uses a form of UDP but is not plain UDP, so no, UDP isn't supported in Adobe Flash.

Well, DarkSocket EXE supports all WinSock protocols, so if I make one for Flash, it'll support all Flash protocols
But with a lack of threads it'll be completely different to the EXE version.