ID:151892
 
I'm no expert in networking but I want opinions from the experienced whether BYOND's networking is efficient enough to support a lot of messages being sent between servers. Examples include trans-world chat and trading. If not, then are there any suggestions for adjustments I could make?
Kakashi24142 wrote:
I'm no expert in networking but I want opinions from the experienced whether BYOND's networking is efficient enough to support a lot of messages being sent between servers. Examples include trans-world chat and trading. If not, then are there any suggestions for adjustments I could make?

Both of those examples actually wouldn't take much in the way of messages, so those examples in particular would work pretty well. Vengeance 56 is an example of a peer-to-peer BYOND game which works similarly, with each player hosting their own version of the game and transmitting their coordinates to the other players in order to take the load off of any central server.

In short, yes, BYOND's network handling is plenty efficient enough for that. Of course, don't expect it to be as fast as a traditional machine-code-developed game using UDP packets. BYOND uses TCP/IP, which incurs some overhead. On the other hand, it does guarantee that all commands and updates will always be received by other clients.
In response to Jtgibson
Oh ok. I was kind of doubting that after seeing a lot of lag from GOA. How efficient is it for sending files that are about 50 kilobytes? How about 1 MB?
In response to Kakashi24142
One caveat which I was about to edit my post to say is that BYOND waits until a transmission is negotiated and completed before continuing (part of the TCP/IP system). Thus, if the other end goes down unexpectedly, it could freeze for some time before timing out. I'm not sure if spawn() helps -- I haven't tested the system as much as I'd like.

As for your response, it depends more on bandwidth than on actual size of the files. I would say that up to 50% of your host computer's upload bandwidth could be transmitted repeatedly with no unexpected slowdowns. Since lots of hosting services are constrained to 384 kbps upload (though thankfully 1 Mbps upload is becoming more common), you're looking at around 48 kB/s as maximum uploadwidth and probably around 24 kB/s as sustainable uploadwidth.

The larger the file, the easier it would be to negotiate because there'd be a larger ratio of file data to overhead. However, bearing in mind that BYOND's current model waits until the transmission completes, you'd notice jittery behaviour on files like that.

Using the Persist parameter of world.Export() should help a lot.
In response to Jtgibson
Ok thanks for all the info!
In response to Kakashi24142
Another person to chat to about this might be Alathon. He's been working on a cluster setup for BYOND for a little while. Last I heard, he had his doubts that Persist parameter was even doing the job.

If all else fails, you could write a UDP DLL and use that.
In response to Stephen001
Stephen001 wrote:
Another person to chat to about this might be Alathon. He's been working on a cluster setup for BYOND for a little while. Last I heard, he had his doubts that Persist parameter was even doing the job.

Well, last I worked with Persist it crashed procs silently if you went from Persist to non-Persist. I haven't messed with it since that was fixed - I'm still unclear on the bandwidth / time gains of even using Persist.

If all else fails, you could write a UDP DLL and use that.

And then I can grab it to use too! ;) I'll be looking into this if no one else does, but thats a 'way in the future' thing for my part.
In response to Alathon
Just a note; if you plan on going the DLL route you'll have to write a Windows DLL and a Linux SO file if you plan on supporting Linux hosting, otherwise the DLL calls will fail.
In response to Nadrew
Nadrew wrote:
Just a note; if you plan on going the DLL route you'll have to write a Windows DLL and a Linux SO file if you plan on supporting Linux hosting, otherwise the DLL calls will fail.

Actually, he would just have to stick to cross-platform libraries and give out the source.

--edit--

I read a bit about it and it seems there is no such cross-platform library for UDP, so nevermind. =)
In response to CIB
CIB wrote:
Actually, he would just have to stick to cross-platform libraries and give out the source.

--edit--

I read a bit about it and it seems there is no such cross-platform library for UDP, so nevermind. =)

http://www.jenkinssoftware.com/
http://code.google.com/p/sckt/
http://sourceforge.net/projects/dyconnect
In response to CaptFalcon33035
Wrong twice, eek. I've also found out that wxWidgets provides a network interface, but the UDP part isn't all too well documented and creating a library that includes all of wxwidgets might be a bit heavy.
In response to CIB
CIB wrote:
Wrong twice, eek. I've also found out that wxWidgets provides a network interface, but the UDP part isn't all too well documented and creating a library that includes all of wxwidgets might be a bit heavy.

I'd like to keep a separation of certain libraries. A GUI library should provide GUI and nothing else, and if you're just looking for UDP support, I don't think wxwidgets is the way to go.
In response to CaptFalcon33035
There is no reason you can't wrap wx for this purpose, it's just I could think of better ways of doing it.
In response to Stephen001
OK, I have started writing that library using the sckt library, now I have two problems.

For one I don't know whether it is possible to handle multiple network interactions with just one socket, but it seems so(except if a socket could not store more than one received message, but that seems unlikely because you should be able to handle an arbitrary number of sockets).

Then I have a big problem concerning type conversion in C++ - I have no idea how to convert the network/host integer into a char* IP-address. There is this function inet_ntop, but I don't know what library provides it for MinGW(works fine in the unix build though).