381 replies to this topic

[Bytewin]

Simple enough for a noob like me to understand.
But very powerful..
Nice! Keep on coding!

[MrRatermat]

I just joined this forum to say, THANK YOU! This has made things much easier!

Without this, i wouldn't bother even making multiplayer games anyway!
You deserve a +1!

[jon sploder]

So Medo, are you going to add mac address functionality or not? I'd really not prefer having to have 39dll for just that and I'm sure many others use that function feel similarly.

[Medo42]

So Medo, are you going to add mac address functionality or not? I'd really not prefer having to have 39dll for just that and I'm sure many others use that function feel similarly.

This somehow dropped from my todo list before I made a new release. I'll fix that soon (probably next week). MAC address detection will be included in some form.

Edit: New version will include bit manipulation functions (bit_get, bit_set and build_ubyte), minimalistic file reading/writing support (read/write an entire file to/from a buffer) and support for querying MAC addresses. The file functions are there because I needed them for Gang Garrison 2 and keeping them in a different branch would be a pain currently because .ged files can't be merged properly. Besides, they might be useful for you as well, and waiting until I have time to start up the Shared Buffers project again isn't a good option

The MAC address function is the last open point now.

Edited by Medo42, 05 February 2012 - 09:36 PM.

[Ronchon le Nain]

Greetings.

While studying different alternatives of 39dll, i found this one too : http dll 2
In this one , the autor refers to an issue of 39dll :

The DLL also fixes an annoying bug/feature in 39dll that can cause data to be lost. With 39dll, the maximum amount of data that can be recieved as a whole is limited by the operating system. Windows will only buffer a fixed amount of data, e.g. 64KB. This might not be enough if you're trying to send large files. If too much data is buffered by the receiver, the sender has to wait to send more data. Since 39dll's sendmessage function doesn't wait, part of the data is lost if too much data is sent at once. This DLL does additional buffering to avoid this problem, so no data is ever lost. You can buffer as much data as you want on both the sending side and the receiving side.

Are you aware of this issue , and is it solved in Faucet Networking ?
Thanks!

[Medo42]

Greetings.

While studying different alternatives of 39dll, i found this one too : http dll 2
In this one , the autor refers to an issue of 39dll :

The DLL also fixes an annoying bug/feature in 39dll that can cause data to be lost. With 39dll, the maximum amount of data that can be recieved as a whole is limited by the operating system. Windows will only buffer a fixed amount of data, e.g. 64KB. This might not be enough if you're trying to send large files. If too much data is buffered by the receiver, the sender has to wait to send more data. Since 39dll's sendmessage function doesn't wait, part of the data is lost if too much data is sent at once. This DLL does additional buffering to avoid this problem, so no data is ever lost. You can buffer as much data as you want on both the sending side and the receiving side.

Are you aware of this issue , and is it solved in Faucet Networking ?
Thanks!

Yes, this is definitely something Faucet Networking solves, it was in fact one of the main problems I had with 39dll which drove me to start this project. If you send a large block of data at once, it will all be buffered and then fed to the operating system by a background thread. For a longer elaboration you can read my 39dll rant in the first post of this thread, and a comparison of the "correct" way to perform a nonblocking send in 39dll and in this extension. It is possible with 39dll, it's just very convoluted :-)

[Ronchon le Nain]

Thanks for the quick answer!
I will definitly consider changing to Faucet then Hope it won't be too complicated.
Keep up the good work !

[orange451]

I was about to be "herpderpderp Gang Garrison used Faucet, you should take their name!". Then I realised you wrote Gang Garrison...

I'm surprised you're still working on the game :3 It's been years since I've played it last.

Very good library though, I can't wait to test it more in depth 8D


[EDIT]
Is there a dll form of this available? I like having these types of things external from my exe's :3

Edited by orange451, 08 February 2012 - 02:17 PM.

[Medo42]

Is there a dll form of this available? I like having these types of things external from my exe's :3

I can include the raw dll in the upcoming update, but I won't include a source file with GML helper scripts at this time. It is worth considering that the use of GML scripts to wrap DLL calls has a considerable overhead.

As for the MAC functionality, I have done some tesing and currently have a function mac_addrs() which returns a comma-separated string with all interface addresses, or an empty string on error (or if no interfaces were found). It automatically excludes loopbacks, tunnel devices and PPP modems.

However, there may still be some interface which does not have a unique physical address, and there is no guarantee either that the addresses are always six bytes long. The function can differentiate between the interface types, but I don't feel a pressing urge to research the physical address format of over 100 different interface types.

Another itchy point is that the function is not very nice to use because Game Maker does not have a string_split function, so to get all the individual MAC addresses you have to iterate over the string like this:

var addrString, pos, mac;
addrString = mac_addrs();
pos = string_pos(",",addrString);
while(pos>0) {
    mac = string_copy(addrString, 1, pos-1);
    addrString = string_delete(addrString, 1, pos);
    show_message(mac);
    pos = string_pos(",",addrString);
}
show_message(addrString);

Since 39dll just blindly takes the first interface and assumes its hardware address to be 6 bytes long, this should give you the same output as 39dll's getmacaddress:

string_copy(mac_addrs(), 1, 17);

Any thoughts?

[orange451]

Do you have a Faucet Network logo? I can put like "Powered by Faucet Networking" or something :3

[Medo42]

Do you have a Faucet Network logo? I can put like "Powered by Faucet Networking" or something :3

Sean A did a logo for Rebound, but I don't have an "official" one. If you want to create one that would be awesome.

[orange451]

Another question. Does this create it's own thread to handle downloading/uploading the packets? If so, would this be a "speed" boost of sorts compared to 39dll which is limited to the room speed?

[Medo42]

Another question. Does this create it's own thread to handle downloading/uploading the packets? If so, would this be a "speed" boost of sorts compared to 39dll which is limited to the room speed?

Yes, this happens in a separate worker thread. In a normal network game situation this should not affect the transfer speed because you will typically send less than a kilobyte over a single socket per step. However, if you want to transfer a large ammount of data with a single nonblocking call per step, I would imagine 39dll to be slower, because the ammount you can send/receive each step is limited by the socket buffer size in the operating system. I did not test this though.

The (imo) most important reason to have the background thread is that it simplifies the interface. Without that (as it was in an early version of Faucet Net), operations that need multiple steps would have to be done in multiple calls to the library. For example, if you call tcp_connect("ganggarrison.com", 80), the library needs to make a DNS query to find the IPs for ganggarrison.com and then attempt to connect. Since the DNS query can take an unpredictable ammount of time and we don't want blocking calls, tcp_connect can only initiate the process and then return. Without a background thread, the library can't start the actual connection attempt until the game hands control back to the library by calling some function, so you need to call into the library at least twice until the connection is actually established. This is usually not a problem because you will be calling networking functions quite regularly anyway, but it makes the behavior of the library needlessly complicated to describe and understand. With a background worker thread, things you initiate will simply be done, no matter how many steps they take and how often you call into the library.

Edited by Medo42, 09 February 2012 - 02:28 PM.

[orange451]

Okay :3


And here's my poor attempt at a "faucet" icon

[Medo42]

Faucet Networking v1.3 is here

- Added new function mac_addrs() to find the physical addresses of installed networking adapters
- Added minimalistic file reading/writing support (append_file_to_buffer(), write_buffer_to_file())
- Added bit manipulation functions (bit_get(), bit_set(), build_ubyte())

Download here

You can also get the raw DLL (not sure how much use this is to anyone though)

Edited by Medo42, 09 February 2012 - 10:14 PM.

[wnsrn3436]

The new version is very nice.
With the addition of file-related functions, the functions of the buffer has been expanded.
Now, people will stay away from 39dll.
This is certainly feature-rich than 39dll, fast and stable.

[orange451]

Can you provide an example on (if possible) how to write and receive bits? Some of my values never exceed 7

[Medo42]

The bit manipulation functions are documented with examples in the help.pdf. There are no functions for reading or writing individual bits from/to buffers and sockets, those only deal with bytes.

[OldSkoolGamer]

Well, here's another take on the above icon for you:

[Medo42]

Well, here's another take on the above icon for you:

Cool, thanks to you and to orange. Yours actually has some connection to networking, but I think it's been a while since Ethernet connections actually looked like that