Jump to content


Photo

Faucet Networking


  • Please log in to reply
379 replies to this topic

#41 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 14 July 2011 - 09:13 PM

Sounding really good there man, Im glad you didnt end up reiving IPv6 support for WinXP.

EDIT:
One problem i seem to be having, the send buffer and recieve buffer just seems to grow and grow without anything actually happening

It doesn't make much sense to me that you say the receive buffer would be growing. TCP sockets in this extension only read data from the Windows socket when you ask them to receive data.
If the sendbuffer grows, this indicates that you are sending data more quickly than it is processed by the receiver, or more quickly than the network can transport.

Some more progress information, I sketched the API for nonblocking hostname lookups today and implemented/documented/wrote unit tests for two functions ip_is_v4 and ip_is_v6 which you can use to find out whether a string represents an IPv4/IPv6 address literal.

Edited by Medo42, 14 July 2011 - 09:27 PM.

  • 0

#42 jobro

jobro

    GMC Member

  • New Member
  • 1247 posts
  • Version:GM8

Posted 14 July 2011 - 10:14 PM

I encountered a minimal problem when opening up .gmk files in 8.1, it doesn't find the extension even though I've installed it. No big deal though since one can always add it in after the file is loaded.
  • 0

#43 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 14 July 2011 - 10:21 PM

I encountered a minimal problem when opening up .gmk files in 8.1, it doesn't find the extension even though I've installed it. No big deal though since one can always add it in after the file is loaded.

This might be unrelated to GM 8.1 - I renamed the extension from "Faucet Networking Extension" to "Faucet Networking" in version 1.0, and forgot to change the reference in the example .gmk files. You might just be getting the error from that.
  • 0

#44 death-droid

death-droid

    GMC Member

  • GMC Member
  • 2599 posts

Posted 14 July 2011 - 11:53 PM

@Medo42, i must of done something wrong, ive sent you what ive coded, i cant see where ive gone wrong -.-
  • 0

#45 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 15 July 2011 - 12:49 AM

@Medo42, i must of done something wrong, ive sent you what ive coded, i cant see where ive gone wrong -.-

Neither can I because megaupload doesn't want me to download this. Try to put the relevant code on Pastebin instead, or just post it here. However, I won't take a closer look at it if all you can be bothered to say is basically "it doesn't work, please fix it for me". Try to describe your problem in a precise and detailled way and I (or someone else) might be able to help you.
  • 0

#46 death-droid

death-droid

    GMC Member

  • GMC Member
  • 2599 posts

Posted 15 July 2011 - 03:27 AM


@Medo42, i must of done something wrong, ive sent you what ive coded, i cant see where ive gone wrong -.-

Neither can I because megaupload doesn't want me to download this. Try to put the relevant code on Pastebin instead, or just post it here. However, I won't take a closer look at it if all you can be bothered to say is basically "it doesn't work, please fix it for me". Try to describe your problem in a precise and detailled way and I (or someone else) might be able to help you.


XD I explained to you whats wrong with it, the receive buffer just seems to grow larger and larger without any processing actually being done, the server seems to also send in chunks of data and not straight away when socket_send is called. The same method used with 39dll works absolutely fine, btw this is just sending to the localhost (127.0.0.1). I've tryed to find out whats causing it at all, everything should be being processed correctly so im left clueless.

Edited by death-droid, 15 July 2011 - 03:36 AM.

  • 0

#47 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 15 July 2011 - 09:47 AM

I had some more time yesterday because people on the floor below me had a party until quite late, so I stayed up a bit and implemented the planned IP lookup functions. There are seven new functions for this, which seems a bit inflationary, but it should be pretty easy to get the hang of it.

The main problem is that lookups can take time, sometimes several seconds, so the API to use them has to be nonblocking. As a result, IP lookups are now resources of their own that have to be created and destroyed. You can create them with ip_lookup_create(hostname), which returns a lookup handle and starts resolving the name. There are also variants ipv4_lookup_create and ipv6_lookup_create, which will only look for IPv4/IPv6 addresses - the default way is to look for both.

After creating them, you can regularly query whether the lookups are finished by calling ip_lookup_ready(lookup), which unsurprisingly returns true once the results are ready. The thing about the results is that there can be several IPs for a single hostname - take google.com for example, which has multiple IPv4 adresses associated with it. In order to read the results, you use the functions ip_lookup_has_next() and ip_lookup_next_result(). The first one tells you if there is another IP in the results that you didn't read yet, and the second one reads the next IP. This is similar to the concept of an iterator, and makes it convenient to loop over all results. For example, the following code queries all IPs associated with google.com and shows a message for each one:

lookup = ip_lookup_create("google.com");
while(!ip_lookup_ready(lookup)) {
    sleep(1); // Or do something useful, like redraw your screen
}
while(ip_lookup_has_next(lookup)) {
    show_message(ip_lookup_next_result(lookup));
}
ip_lookup_destroy(lookup);

Edited by Medo42, 15 July 2011 - 09:49 AM.

  • 1

#48 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 16 July 2011 - 11:45 PM

More progress: I updated the documentation with the new IP lookup functions and played around with hostname resolution a bit. In the end, I decided to allow using hostnames in UDP send after all, since you sometimes just want to send a few packets where the overhead of the extra lookup isn't a big problem, and it's just a bit more convenient that way. It's also more consistent, since tcp_connect allows hostnames as well.

There are still a few things to do, but we're getting closer :)
  • 0

#49 8-BitTonberry

8-BitTonberry

    GMC Member

  • GMC Member
  • 557 posts
  • Version:GM8.1

Posted 18 July 2011 - 04:25 AM

Normally, I'm pretty good with these things, but would there be any chance you could give a brief explanation about how to send and receive variables?

Thanks! =]

This is pretty amazing, by the way.
  • 0

#50 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 18 July 2011 - 06:51 PM

Normally, I'm pretty good with these things, but would there be any chance you could give a brief explanation about how to send and receive variables?

Thanks! =]

This is pretty amazing, by the way.

To send something, you need to write it into the socket's sendbuffer first. You can write the value of a variable there using the write_X functions. If the variable contains a number, you can e.g. write
write_double(socket, variable)
in order to write the value with full precision. If it's a string, you can use
write_string(socket, variable)
- however, in order to receive the string on the other side you need to know how long it is, so it's a good idea to write the length of the string first.
Then you call socket_send(socket) to actually send your data.

Receiving works by calling one of the tcp_receive functions and then using something like
variable = read_double(socket)

  • 0

#51 8-BitTonberry

8-BitTonberry

    GMC Member

  • GMC Member
  • 557 posts
  • Version:GM8.1

Posted 19 July 2011 - 05:43 PM

Alright, that's simple enough. Hah, thanks! =]

What about the bytes? In the Pong example I'd noticed there was an expectedBytes variable, to throttle the sent data, I assumed. How do I know how many bytes are to be sent? The only way I can figure it out is to just make the sent bytes larger than necessary, or keep increasing and testing until it works.
  • 0

#52 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 19 July 2011 - 06:08 PM

Alright, that's simple enough. Hah, thanks! =]

What about the bytes? In the Pong example I'd noticed there was an expectedBytes variable, to throttle the sent data, I assumed. How do I know how many bytes are to be sent? The only way I can figure it out is to just make the sent bytes larger than necessary, or keep increasing and testing until it works.

This has nothing to do with throttling. When you transfer data in a networking game, you usually think in terms of "messages". An example would be the BALL_UPDATE message in the pong example, which contains the x and y position of the ball and its horizontal and vertial speed. You want to receive a message completely before you start processing it, because it's no good if you only get the x position and the first byte of the y position. However, TCP treats all data as a stream of bytes without any seperation of messages.

In the example this is solved by prefixing every message with its length. As a result, the code always alternates between reading that single length byte and the actual message of that length. expectedBytes simply contains the number of bytes of the next "thing" that should be received, either the length byte or the message.
  • 0

#53 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 22 July 2011 - 12:09 AM

A bit of progress once more: I continued expanding / adapting the documentation. Additionally, I changed the TCP acceptor code to use the new method for binding the IPv4 and IPv6 sockets that I wrote for the UDP socket. As a result, you can now call tcp_listen(0) to listen on a random unused port. This might not be all that useful for people behind a router/firewall, since they need to use a fixed port to set up port forwarding, but it's nice to have the option :).

All in all, I think this is shaping up nicely. I can probably release a beta version this weekend.
  • 1

#54 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 23 July 2011 - 04:04 PM

Finally, it's done. This has been a far bigger change than I had anticipated, but it looks like the UDP support is ready now.
So, quite how big of a change is this latest version? Here is what git diff --stat tells me about the difference between V1.0 and V1.1:
26 files changed, 980 insertions(+), 315 deletions(-)
Considering that there were only around 2000 lines total in V1.0, this is rather significant. And this does not include the changes to the documentation, which has been updated and expanded.

Here's an overview of the most interesting changes:
  • Added UDP sockets. Create them with udp_bind(port), then write data to their send buffer and send it as a datagram with udp_send. You can receive a datagram in to the socket's receive buffer with udp_receive.
  • Added functions for manually resolving hostnames to IP addresses
  • Added possibility for acceptors and UDP sockets to bind to a random unused port, by passing 0 as port number to udp_bind and tcp_listen.
  • Added a function socket_local_port to query the local port of a sockets or acceptors
  • Added a function socket_remote_port to query the remote port of a TCP connection or a received UDP datagram

You can download the new version here. Keep in mind that this was a big change, so be prepared to encounter bugs, especially in the new functions. I did test things, but not extensively. Report any problems that you find, and I'll try to fix them quickly.

One more thing. Developing this extension is a lot of work. I'm doing it in my spare time and provide the result for free and as open source. However, in case this extension helped you and you want to support me in return, you can Flattr me. Thanks :)
  • 0

#55 jon sploder

jon sploder

    GMC Member

  • GMC Member
  • 858 posts

Posted 24 July 2011 - 03:54 AM

Great! Downloaded and testing...:

On running the pong example, closing one of the games (I think it was the client, but it probably occurs regardless):
Posted Image

FAUC! xP

It's a pretty good example :). I'll try and write a basic chat program if I have time later, and report any bugs.

Edited by jon sploder, 24 July 2011 - 03:55 AM.

  • 0

#56 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 24 July 2011 - 08:10 AM

Great! Downloaded and testing...:

On running the pong example, closing one of the games (I think it was the client, but it probably occurs regardless):
Posted Image

FAUC! xP

It's a pretty good example :). I'll try and write a basic chat program if I have time later, and report any bugs.

Hmm, I thought I had fixed that. It doesn't happen for me either, so I tried to fix the most likely cause now.

If you can reproduce the problem, please see if this helps: http://www.ganggarri...cetnetv111a.gex

Edited by Medo42, 24 July 2011 - 08:11 AM.

  • 0

#57 jon sploder

jon sploder

    GMC Member

  • GMC Member
  • 858 posts

Posted 24 July 2011 - 09:32 AM

I can replicate it every time I close the pong example, even with that extension update in the link.
  • 0

#58 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 24 July 2011 - 10:04 AM

I can replicate it every time I close the pong example, even with that extension update in the link.

I will take a closer look this evening.
  • 0

#59 Medo42

Medo42

    GMC Member

  • GMC Member
  • 219 posts

Posted 24 July 2011 - 12:50 PM

I found the problem. Here, have another digit in the version number ;)

Download verison 1.1.1 here.
  • 0

#60 Knuked

Knuked

    GMC Member

  • New Member
  • 242 posts
  • Version:GM:HTML5

Posted 26 July 2011 - 12:22 AM

Fantastic work Medo. I was rather surprised that there wasn't a new example using UDP. It's easy enough for myself, but I can imagine new people to Faucet or online programming in general may struggle without something to look at. Can people expect an example in the future? If I get some more time I could possibly make one I suppose :)
  • 1




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users