[NO CCU LIMIT] Forge Networking now OPEN SOURCE

We are having a little bug with the RPC on the new system, so I do not want to send the build tonight. I need to head to bed in order to wake up very early tomorrow to teach. However! The weekend is here and that will give me plenty of time to work out the bugs!

We are still having people request the Beta of the system! Thank you all!

Notes about the release. I will be sending out the Beta to the people who requested of the last 2 days the beta V6. I am hoping to have Beta V7 out tonight after I have fixed the bug with the RPCs. It is much faster and has WAY less garbage collection.

We are still taking as many Beta testers as possible! If you are reading through and want to get a beta build, just send me an message with your email or send an email to: support@beardedmangames.com with the subject line "Forge Networking Beta".

We have not cleaned up all of the garbage collection just yet, however we have reached our goal to getting the time for the read call to be at the very least ~0.4 milliseconds (400 microseconds). We HEAVILY modified the core libraries and wrote some new classes to manage memory, objects and sockets. We ARE NOT done with optimizing this as we are trying to get our time even lower than 0.4 milliseconds. Our next goal is to try and get it to around 200 microseconds. Once we reach that we will attempt to make it even faster!

I will be pushing out Version 7 soon as I am sure there are places in V7 that may have issues. However I have been testing all day and have worked out the majority that I could find. So, look for V7 in your inbox!

Sorry for my hiatus the past couple of days! We were doing HEAVY refactoring of the core system to really push a bleeding performance on the new build. We made the system so fast that we found threaded bugs where our threads were kicking off so fast that it would connect even before you could register a connection event callback XD. So I am sure there will be SPEED related bugs that may come up in your integrations... but that sounds like a good problem to have

Compared to V7, V6 is a sloth and we are hoping to make the future version make V7 look like a sloth as well!

Thank you all for your continued feedback, support and feature requests! So, we are going to keep going over the speed optimizations (and the current GC optimizations) however we are going to start working on some suggested features as well for V8!

Hello all!
I just sent out Beta V7! Please let me or Brett know if you are having any issues with the new build. Note that you may have to change some of your code if any of the function signatures changed (no legacy/deprecated code will be left in our beta builds).

That is what we do! We are BLAZING through our implementation and tests! We have been a bit quiet the last few days but that is because we were refactoring the entire core system (keeping the same design). Now we are back and ready to see how new features set on top of our shiny new core!

Indeed! Sorry that we couldn't get that out this build . We just didn't want to send out a "lemon". My hope is that we can get some of the feature requests into V8 and have the Win8.1 and WP8.1 build in and working soon.

NOTE: I got a couple of emails back saying "Delivery Status Notification" and having some weird in-readable error. If you did not get Beta V7 please send me a message saying so! It did not tell me who got it and who didn't

NOTE: I got a couple of emails back saying "Delivery Status Notification" and having some weird in-readable error. If you did not get Beta V7 please send me a message saying so! It did not tell me who got it and who didn't

Click to expand...

the email you sent is from an unknown sender .., maybe that's the reason

This is an amazing networking solution because it runs in Unity instances. One could simulate an entire world on the server and make sure all physics calculations in that world are in sync. Cheating could be 100% prevented by simulating all actions on the server (moving, attacking, etc.).

At the moment, performance is an issue. The majority of people don't have very powerful computers to host servers on so there should be enough optimization to allow for multiple instances running on a single computer (for multiple games) or a load balancing system.

Already, I can see MMO's running super efficiently without cheaters or desyncs but with some optimization, FPS's and many other games can as well.

This is an amazing networking solution because it runs in Unity instances. One could simulate an entire world on the server and make sure all physics calculations in that world are in sync. Cheating could be 100% prevented by simulating all actions on the server (moving, attacking, etc.).

Click to expand...

Thank you for the kind words! We are actually working with making our own games with this networking as well. That is one of the reasons we have developed it in the Unity way. We felt that there wasn't anything out there that suited what we wanted to do after looking and working with all of the other systems. So we began work on Forge!

At the moment, performance is an issue. The majority of people don't have very powerful computers to host servers on so there should be enough optimization to allow for multiple instances running on a single computer (for multiple games) or a load balancing system.

Click to expand...

Are you running Beta Version 7? We changed the entire core and may have missed something on our thread manager. Is your frame-rate going down or is it that your CPU % is too high? I will double check the threads tonight!

Already, I can see MMO's running super efficiently without cheaters or desyncs but with some optimization, FPS's and many other games can as well.

Click to expand...

We are in the middle or making optimization passes now . One of the games we are working on developing requires some heavy real time information so we will keep on working to make that as efficient as possible.

EDIT: Looking at the email you sent now*

EDIT 2: Okay, this is definitely a threading bug. I should have it worked out tonight!

You are correct. We factored the entire core and were so anxious to get you guys the new build we forgot to double check the thread system! Since we know exactly where to look for this issue we will most likely have a build tonight.

and hopefully this time that nasty gremling will be squashed with no resuscitation mode for good.

Click to expand...

Haha, it should be! The only reason it came up again was because of the core system refactor. With the new structure we won't need to do an overhaul like that again anytime soon. We will just be working over the shiny new core to optimize performance. So I'm pretty confident that it won't show itself again after this!

Thread issue solved! Brett is pushing out Beta V7.2 hotfix now! Now** you should see MASSIVE performance increases from V6 and earlier (in bandwidth, garbage collection, and so forth). Please let us know if this one is working properly for all of you.

Unfortunately, I couldn't get it to work. I'll try it again when NAT Punchthrough is implemented but it's not a big deal because I'm nowhere near needing to use the cloud server.

Click to expand...

Bah! Yeah, we have been taking features quickly, we will promote NAT Punchthrough though! We have been testing on LAN mainly and not just localhost so we shouldn't have any problems once we input NAT punchthrough.

Forge seems to be quite a good balance between simple implementation and advanced developer features. I would love to get started testing the library to see if it could work out for our a new (non-game) 3D application I'm starting to develop.

Forge seems to be quite a good balance between simple implementation and advanced developer features. I would love to get started testing the library to see if it could work out for our a new (non-game) 3D application I'm starting to develop.

Would you like to add me to the Beta group?

Thanks!

Jeroen

Click to expand...

Awesome! We would love to have you testing out the system! Since we are developing this system for our own games and applications as well, we are doing everything we can to make it simple for those who are just implementing while still giving all the bare metal power to the power programmers.

We are constantly looking for feature requests, bug reports and feedback so feel free to let us know anything you have in mind!

I have hit a wall migrating my FPS project to forge networking. I need a way to tell which player sent a message to the server.

Is there a way to tell which player sent the message?

Also, on the client side, for the player to know what their player ID is on the server?

I can see the player IP on sender, but the client doesn't know what their IP is. So I can't Xref this. Also, you may have a situation where you have multiple clients with the same IP, if more than one person is playing behind the same internet connection.

I have hit a wall migrating my FPS project to forge networking. I need a way to tell which player sent a message to the server.

Is there a way to tell which player sent the message?

Also, on the client side, for the player to know what their player ID is on the server?

I can see the player IP on sender, but the client doesn't know what their IP is. So I can't Xref this. Also, you may have a situation where you have multiple clients with the same IP, if more than one person is playing behind the same internet connection.

Click to expand...

Hey! If you have hit a wall we can probably push a hot fix as we are in the middle of some changes now.

Currently the sender (on the clinet) will be the server, no matter who sent it. You could probably do logic to send some extra data about the sender id from the sender in the message, but we can work in the sender id on the server side too.

The "NetworkId" is the current players id. So you can get the player id for the current player with the myNetWorker.Uniqueidentifier.

Would us adding the RealSenderId as a part of the sender message work for you? Or do you have a suggestion on what would help out better?

I am designing a system of pushing out all of the players id's to each player so that they are able to identify and request for the server to send targeted RPC calls and other information from one player to another, rather than the default Unity style, all, server or others.

Edit: I would like to append that I will be allowing for a "name" variable as a part of the players, so that clients can then easily identify other players by something other than an indexed number

Click to expand...

The player ID would need to be passed when using WriteCustom so the receiver knows who sent it. I only need this to work with client to server communication. i.e. don't need player id for communication sent client to client or server to client.

I could probably use the myNetWorker.UniqueIdentifier and do some handshaking when a client first connects. eg:
1. On client connected. Client sends their uniqueIdentifer + their name to the server
2. Server adds this to a collection and broadcasts to all players
3. players update their own copy of the collection
Finally, add the uniqueIdentifier as data I send in each message to server.

I considered doing this last night, but was hoping that the Player ID feature might be coming soon. If you are more than a week away with this feature, I will write a temporary solution. But if it is close to the top of your to-do list, I will wait.Do you have an ETA?

The player ID would need to be passed when using WriteCustom so the receiver knows who sent it. I only need this to work with client to server communication. i.e. don't need player id for communication sent client to client or server to client.

I could probably use the myNetWorker.UniqueIdentifier and do some handshaking when a client first connects. eg:
1. On client connected. Client sends their uniqueIdentifer + their name to the server
2. Server adds this to a collection and broadcasts to all players
3. players update their own copy of the collection
Finally, add the uniqueIdentifier as data I send in each message to server.

I considered doing this last night, but was hoping that the Player ID feature might be coming soon. If you are more than a week away with this feature, I will write a temporary solution. But if it is close to the top of your to-do list, I will wait.Do you have an ETA?

Click to expand...

I would actually enjoy the break from the current task as it may take little longer to complete. I think we can get the feature you are requesting here in within 1-2 days!

Also if you have to manually make any kind of feature let us know (if you think it would be helpful to be built in). I know that we provide a lot of lower level access to accomplish most all the features that come to mind, however if we directly embed it into the system we may be able to see better bandwidth and performance come out of those systems that could very well be critically contingent on performance/bandwidth. As always we will be happy to provide very simple ways to turn on and off any system that is requested to be added as well as an easy way to configure it! (ie: updating players based on range).

We will be getting back to the documentation soon as well by the way! We know how critical it is to document how to use all the new features we implement.

Also if you have to manually make any kind of feature let us know (if you think it would be helpful to be built in). I know that we provide a lot of lower level access to accomplish most all the features that come to mind, however if we directly embed it into the system we may be able to see better bandwidth and performance come out of those systems that could very well be critically contingent on performance/bandwidth. As always we will be happy to provide very simple ways to turn on and off any system that is requested to be added as well as an easy way to configure it! (ie: updating players based on range).

Click to expand...

I certainly will let you know
Initially I am doing a straight migration and then I will replace any functionality that forge can provide.
One feature that might already exist, but I couldn't find in doco is time synchronisation. Do clients have access to server time so all clients can work on the same clock?

To use a BMSByte you can new up one with just new BMSByte(). We will build out a new HTML documentation with V8 tomorrow. As for now here is a quick summary of BMSByte functions:

// Add bytes to the end of the byteArr
public void Append (byte[] input)
// Copy an object and convert to bytes to the end of byteArr with a specific size
public void BlockCopy<T> (object obj, int count)
// Copy an object and convert to bytes at the end of byteArr
public void BlockCopy (object obj)
// Copy part of a byte array to the byteArr
public void BlockCopy (byte[] input, int start, int count)
// Empty(ish) out byteArr
public void Clear ()
// Clear the current byteArr and clone the other BMSByte object into this one
public BMSByte Clone (BMSByte otherBytes)
// Clear out the current byteArr and clone the passed array into BMSByte
public void Clone (byte[] input)

Using the BMSByte class will prevent 99.9% of garbage collection over time

Also: I will have to release Version 8 tomorrow night because I found a bug with the server sync time that I do not want to release with. It is super late here and I don't think I can track it down tonight. (4am here), gotta get up for work tomorrow! XD

Thx for the answer on the byte array. I haven't tried it yet. But that's perfect.

I may have misunderstood your previous post regarding sender ID. My code is broken at the moment as I do some reshuffling. So I haven't been able to check this. When a client calls writecustom. Does the NetworkSender parameter have the network ID for the client correctly set when received on the server in Beta 7 or 8? If this is already working, I am not so desperate for the changes discussed above.

Thx for the answer on the byte array. I haven't tried it yet. But that's perfect.

I may have misunderstood your previous post regarding sender ID. My code is broken at the moment as I do some reshuffling. So I haven't been able to check this. When a client calls writecustom. Does the NetworkSender parameter have the network ID for the client correctly set when received on the server in Beta 7 or 8? If this is already working, I am not so desperate for the changes discussed above.

Click to expand...

In V8 you will be able to use the NetworkingStream to get the actual senders id with: stream.RealSenderId, which will be the actual ulong id for the player who sent it (before it was relayed by the server). I already have this working in V8, I am just sorting out a bug that is happening with the ServerTime tonight and then will send it out.

the above 2 features for any given multiplayer game beeing simple multiplayer or large scale mmo is a bitch to implement, so if this is basic must have from any multiplayer game, why not make it an out of the box feature from Forge networking.

you will save anyone lots of time and hair pulling headaches

just a thought, maybe some others would like to do it them selves but to me it is a hassle, ive work with several networking engines and none offer this feature, wouldnt it be nice to have it.
ulink has something similar, dbmanager,authmanager,accnt mgr, lobby mgr, friends atc,, but it all saves to riak no sql db, what???? i have never hear it in my life, most of us dont even know there was such a db, why not make it the default everyday most common db which is mysql.

offcourse that is if farris you wont find it a bitch to work with(auth and db managers), then that will be 2 of us then, lol

I agree with GraphX. An authentication manager would be an amazing feature that's necessary for nearly all games so the package might as well save many developers a lot of time by already implementing the feature.

A database manager would be useful as well, but not just for player in-game specific data. It would be nice if with just 1 method SetStat (string Player, string Stat, int Data) to set a single integer corresponding to a stat of a player (maybe in a dictionary of dictionaries) then similarly retrieve data with RetreiveStat (string Player, string Stat) for when the player logs back in or wants to check his kill/death ratio.

the above 2 features for any given multiplayer game beeing simple multiplayer or large scale mmo is a bitch to implement, so if this is basic must have from any multiplayer game, why not make it an out of the box feature from Forge networking.

I agree with GraphX. An authentication manager would be an amazing feature that's necessary for nearly all games so the package might as well save many developers a lot of time by already implementing the feature.

A database manager would be useful as well, but not just for player in-game specific data. It would be nice if with just 1 method SetStat (string Player, string Stat, int Data) to set a single integer corresponding to a stat of a player (maybe in a dictionary of dictionaries) then similarly retrieve data with RetreiveStat (string Player, string Stat) for when the player logs back in or wants to check his kill/death ratio.

Click to expand...

Thank you both for the feedback. So, not to blow the lid off of any plans just yet but-- I would like you to know that we have heavy database integration plans with the following: MySQL, CouchBase, Redis, and our own proprietary Key-Value store (will reside within server implementation), we have already developed our own multi-threaded persistent memory-to-file based key-value store that will find its way into one of these releases.

During my day job I develop on, with, and for all of the mentioned databases. I have quite a lot of experience with these databases and I know how valuable they are. So do not fear! You will have all the data storage you could ever want. There are other things that we have designed that are within this realm, however I am not at liberty to talk about them at this time . You will see these BIG features starting to creep their way out very soon

To use a BMSByte you can new up one with just new BMSByte(). We will build out a new HTML documentation with V8 tomorrow. As for now here is a quick summary of BMSByte functions:

// Add bytes to the end of the byteArr
public void Append (byte[] input)
// Copy an object and convert to bytes to the end of byteArr with a specific size
public void BlockCopy<T> (object obj, int count)
// Copy an object and convert to bytes at the end of byteArr
public void BlockCopy (object obj)
// Copy part of a byte array to the byteArr
public void BlockCopy (byte[] input, int start, int count)
// Empty(ish) out byteArr
public void Clear ()
// Clear the current byteArr and clone the other BMSByte object into this one
public BMSByte Clone (BMSByte otherBytes)
// Clear out the current byteArr and clone the passed array into BMSByte
public void Clone (byte[] input)

Using the BMSByte class will prevent 99.9% of garbage collection over time

Also: I will have to release Version 8 tomorrow night because I found a bug with the server sync time that I do not want to release with. It is super late here and I don't think I can track it down tonight. (4am here), gotta get up for work tomorrow! XD

Click to expand...

I can't see the class BMSByte, I think the obviscation it renaming it.to a.e. see type in screen dump below.

Edit: I guessed how to use a.e.
However I hit another problem with Beta 8. The state of the client no longer changes to connected. The host can see the client connect, events fire as normal. But on the client side, polling Networker.Connected always stays false and connected event never fires. Switching back to Beta 6.1, my code connects ok.

I can't see the class BMSByte, I think the obviscation it renaming it.to a.e. see type in screen dump below.

Edit: I guessed how to use a.e.
However I hit another problem with Beta 8. The state of the client no longer changes to connected. The host can see the client connect, events fire as normal. But on the client side, polling Networker.Connected always stays false and connected event never fires. Switching back to Beta 6.1, my code connects ok.

Click to expand...

Woah! It looks like our obfuscator isn't setup to play nice with sealed classes! We will have this fixed as soon as we get home form work tonight! Thank you for pointing this out. I think we just need to setup our rules for any sealed classes. Should only take a minute to fix once we get home. Also I agree about jumping back to 6.1 later today, at it's current state the BMSByte is not user friendly at all

However I hit another problem with Beta 8. The state of the client no longer changes to connected. The host can see the client connect, events fire as normal. But on the client side, polling Networker.Connected always stays false and connected event never fires. Switching back to Beta 6.1, my code connects ok.

Click to expand...

Another question:

TCP and/or UPD and/or R-UDP
I have another question on reliable vs unreliable packet delivery. I am currently just using the writecustom method for all network communication over UDP. Sometimes I need to send packets unreliable, other times they need to be reliable. How should I implement this with Forge Networking?

In previous posts you answered that there is no relationship between 2 networkers and so their is no easy way to setup a connection between client and server that is both reliable and unreliable.

My understanding of networking is rudimentary, so please correct me if this is wrong.

TCP will guarantee delivery and order of packets. The datagram sent between the sender and receiver will typically have several hop's along the way. Say we have:
H=Host computer
C=Client computer
R1, R2, R3 are routers that the datagram routes through to get from H to C.

So datagram transmission time is 40ms. A ping, which needs a full round trip will be 80ms.
If a packet is lost/damaged on one hop, say between R1 and R2, R1 will re transmit and this packet will take 50ms to get from H to C.

If I use UPD and need to guarantee delivery of a packet, I need to implement my own handshaking, so H sends datagram, C receives datagram and sends an acknowledgement back to H.

If H does not receive acknowledgment, say within ping time + a constant, lets make it 90ms, H will resend datagram. So for a datagram that is resent, it will take 90+40=130ms to reach client.

This is much longer than the 50ms using TCP. So for data I want to Guarantee reaches the client, I want to use TCP.

I don't understand R-UDP. Is it similar to TCP, retransmissions take 50ms, or is it implemented between the host and client so retransmissions will take 130ms?

I am just not sure how to manage both reliable and unreliable network traffic using Forge and ensure that I get the best of both worlds, fast unreliable messages and the fastest reliable messages?

I have another question on reliable vs unreliable packet delivery. I am currently just using the writecustom method for all network communication over UDP. Sometimes I need to send packets unreliable, other times they need to be reliable. How should I implement this with Forge Networking?

Click to expand...

Before I go into too much detail, you can continue to use UDP for WriteCustom because one of the arguments is a bool "reliableUDP" which if set to true will use Reliable UDP as we have reliable UDP built into the system.

So, the first difference between TCP and UDP is with the connection. Since UDP is connection-less it actually can blast messages at very fast speeds to an endpoint without any authentication or overhead. The endpoint can choose to accept it if it is listening on that port, or it's firewall will block the message, or the packet(s) could be dropped. This method makes UDP "un-reliable". TCP does a 3 way handshake for its connection. The client will do a sync packet to the server, the server will send back a sync-acknowledgement then the client will send an acknowledgement back to the server, from there the connection is established.

Now that the TCP connection is established every message will be sent in order and will make sure that it will get from one machine to the other (the endpoint will need to send an acknowledge packet upon receive). Packets can be lost, damaged or duplicated and TCP auto-magically fixes any of these problems. UDP, as noted before, does not care about these problems. When TCP sends a message it will send packets and wait for responses and then send more in the order they need to be received. UDP will not care about the order and send them as fast as possible. TCP will automatically chunk up the data and send it in pieces where in UDP you will control your packet size. TCP also reads the data as one continuous stream not caring where one piece of data starts or ends (so you will need to manage the pieces yourself). UDP guarantees that the packet will be whole and it will read only 1 packet at a time without merging them. Because of this, when there is a problem in TCP it will need to stop the stream and reorder the pieces after the request for the missing (or out of order) packet is sent. This makes TCP much slower than UDP and even slower than R-UDP (depending on your resend times).

Sustainability is another thing to know about using the two. If you lose your connection in TCP you will need to re-establish it. This means if you are not constantly sending data over TCP you will need a "keep alive". Which is just some data you send at a time interval to keep the connection going. If you lose the connection you will need to redo the connection from the beginning.

Reliable UDP is an emulation of TCP that that is done through UDP. So things like sending whole packets rather than one continuous stream can be taken advantage of. If messages are really far apart you do not need a "keep alive" because UDP is connection-less. So though you will wait at an interval before re-sending a packet from Reliable UDP the key is that you can use many algorithms to make this better. You can do things like getting the average ping time to the other client and use that to be how long you wait before a resend. There are many individual solutions to Reliable UDP that can be taken advantage of. However that means you will need to write all the TCP like elements into the Reliable UDP system yourself. Things like: the order of packets, telling the sender that the packet was received, prevent overflow, message timeouts, re-sending messages, etc. We have all of these things (and more) built into our Reliable UDP implementation so that you do not have to worry about them.

Please let me know if I didn't fully answer your question! I would be happy to help any way that I can

Ah! Sorry, yes, we had an email last night about connection related bugs and will be checking out these problems tonight as well

Before I go into too much detail, you can continue to use UDP for WriteCustom because one of the arguments is a bool "reliableUDP" which if set to true will use Reliable UDP as we have reliable UDP built into the system.

So, the first difference between TCP and UDP is with the connection. Since UDP is connection-less it actually can blast messages at very fast speeds to an endpoint without any authentication or overhead. The endpoint can choose to accept it if it is listening on that port, or it's firewall will block the message, or the packet(s) could be dropped. This method makes UDP "un-reliable". TCP does a 3 way handshake for its connection. The client will do a sync packet to the server, the server will send back a sync-acknowledgement then the client will send an acknowledgement back to the server, from there the connection is established.

Now that the TCP connection is established every message will be sent in order and will make sure that it will get from one machine to the other (the endpoint will need to send an acknowledge packet upon receive). Packets can be lost, damaged or duplicated and TCP auto-magically fixes any of these problems. UDP, as noted before, does not care about these problems. When TCP sends a message it will send packets and wait for responses and then send more in the order they need to be received. UDP will not care about the order and send them as fast as possible. TCP will automatically chunk up the data and send it in pieces where in UDP you will control your packet size. TCP also reads the data as one continuous stream not caring where one piece of data starts or ends (so you will need to manage the pieces yourself). UDP guarantees that the packet will be whole and it will read only 1 packet at a time without merging them. Because of this, when there is a problem in TCP it will need to stop the stream and reorder the pieces after the request for the missing (or out of order) packet is sent. This makes TCP much slower than UDP and even slower than R-UDP (depending on your resend times).

Sustainability is another thing to know about using the two. If you lose your connection in TCP you will need to re-establish it. This means if you are not constantly sending data over TCP you will need a "keep alive". Which is just some data you send at a time interval to keep the connection going. If you lose the connection you will need to redo the connection from the beginning.

Reliable UDP is an emulation of TCP that that is done through UDP. So things like sending whole packets rather than one continuous stream can be taken advantage of. If messages are really far apart you do not need a "keep alive" because UDP is connection-less. So though you will wait at an interval before re-sending a packet from Reliable UDP the key is that you can use many algorithms to make this better. You can do things like getting the average ping time to the other client and use that to be how long you wait before a resend. There are many individual solutions to Reliable UDP that can be taken advantage of. However that means you will need to write all the TCP like elements into the Reliable UDP system yourself. Things like: the order of packets, telling the sender that the packet was received, prevent overflow, message timeouts, re-sending messages, etc. We have all of these things (and more) built into our Reliable UDP implementation so that you do not have to worry about them.

Please let me know if I didn't fully answer your question! I would be happy to help any way that I can

Click to expand...

Thanks that is a fantastic response and I understand your explanation.

But it doesn't answer the question I have. Which I realize I didn't articulate very well. I have tried Googling this, but cannot find an answer (which is amazing because Google Knows all )

I'll rephrase my question and keep it simple.

My questions relate to a very specific scenario:

"Our server is in New York, a client is in London. A single packet is sent from server to client. the packet is lost once between two routers (which take 10% of the journey time) and needs to be resent. The resent packet is received at the client. Calculate the time between when the packet was first sent from the server until it was received at the client."

Question 1. Which is faster R-UDP or TCP?

Question 2. Approximately how long does it take this packet to get to the client over R-UDP?(i.e. If the packet got through without needing a re-transmission: Transmission Time = PING_TIME / 2)

Question 3: Approximately how long does it take this packet to get to the client over TCP?

Question 2. Approximately how long does it take this packet to get to the client over R-UDP?(i.e. If the packet got through without needing a re-transmission: Transmission Time = PING_TIME / 2)

Question 3: Approximately how long does it take this packet to get to the client over TCP?

Click to expand...

1) In the long run Reliable UDP will be faster
2 & 3) Since distance is key in this, a solid number can not be given. Logically (once sent) it will take just as long for a TCP packet to reach the other end as a UDP, it is all of the error checking and ordering and back and forth that slows down TCP.

Fellow Forge supporters: I've created reviews of a variety of networking solutions and wrote positively about Forge. Unfortunately, I haven't been able to spend as much time with Forge because it would be more efficient for my game to run in pure .net logic but I definitely want to see more of this networking solution as a (better) alternative to uLink. If there's any late developments or planned features I missed, tell me and I'll add it into the review. Check it out here: http://forum.unity3d.com/threads/mu...oton-ulink-darkrift-forge-and-playfab.294852/.

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.