[NO CCU LIMIT] Forge Networking now OPEN SOURCE

well, i thought about that, but the minigames/battlegrounds setup i plan on using mostly will be 1vs1 or 2vs2 so, in a 400 or 500 ccu setup per hardware node, having 250 unity instances with 2 or 4 players in it in one hardware node will make the difference very noticiable.
so if i can have at least 10 minigames sessions per unity instance will be more effective for my setup.

my goal is to have 10 session wiht totaling max of 40 players per unity instance to not overload it so the minigame sessions will run smooth.

this way 10 or 20 instances running in the same node with 10 sessions on each can work better that 250 instances imo, maybe i am wrong and may back fire on me but in threory sounds more appealing. hopefully it will be the same in practice

 

For those who found that the website had incorrect information about Networking.Socket.connect or any "Networking.Socket" stuff, we are addressing the issue. Since we added the ability for the Networking class to have many connections, we need to update these on the site (doing so now) to Networking.Sockets[port].connected and so on.

 

So i have a problem with instantiating.

Code (csharp):

1.  
2.  
3. void Update()
4. {
5.         if(!_connected && Networking.Sockets[port].Connected)
6.         {
7.             Connected();
8.         }
9. }
10.  
11. private void Connected()
12. {
13.       if (!Networking.Sockets[port].IsServer)
14.       {
15.             Networking.Instantiate(Player, new Vector3(5.0f, 5.0f, 0.0f), Quaternion.identity, NetworkReceivers.AllBuffered);
16.       }
17.       _connected = true;
18. }
19.  
20.  

I got a server instance and a client instance as i am testing the setup as full authoritative. The player send key inputs to the server and then moves locally, the server moves the 'client' on the server and then update other players and corrects the player himself. Pretty simple stuff.

The problem comes when i join multiple clients:

1. The server is instantiated and does not spawn a player, so good so far.
2. Client one joins, a player is created and is controlled correctly by the client. so good so far.
3. Client two joins. A player is created on the server and on client one, BUT there is no players on client two at all.
The new player character does act correctly though as neither the server or client one can control it.

So maybe a bit more information on instantiate would be awesome! Otherwise it is already working pretty well and i already started playing around with the idea of creating my own loadbalancing system for multiple server instances on multiple servers

 

Awesome!

Well, My first question would be to ask if you are connecting via UDP and if it is on the same machine?

If yes:
UDP will only allow you to connect 1 client from the same machine due to its nature of needing IP and port (which would be the same on multiple clients for the same machine). I should probably add better logging for these kinds of problems*. A way that you can test this (if you don't want to launch on tons of devices) would be to temporarily switch to TCP as your main form of communication as it binds differently. We do plan to look into/work on same machine, multiple UDP clients on the same port.

If no:
We will look into this to make sure we didn't mess up anything in our V2 Beta build

Awesome that you figured out the instantiation, we were actually going to do our tutorial videos on that tonight.

 

I'd like to see some server cpu and memory stats that back up your statement.
Why not do a comparison and post the results here?

 

Hey guys, I have just sent out Beta V3. I am sure I sent it out to everyone, but let me know if I missed anyone!

Major fix: Threading controller fixed - No more maxing out CPU, should be stable and very low

 

I would to have access to the Beta of this, maybe we can share some ideas and feedback!

 

Heys guys,

It will be nice to have like the lidgren library a server discovery feature. ( https://code.google.com/p/lidgren-network-gen3/wiki/Discovery )
Client send a broadcast message, and the server reply to this client.
The client knows the ip of the server and can connect

 

Thanks for the new beta 3,

awesome, more testing here,

Something is still not right tho, you getting close but still.

I still get some weird threading behavior.
maybe the issue is my oldie 4 year old intel quadcore dev box.
specs:
8 gb ram
gforce gtx 650 gpu 2 gb ram
Win7 enterprise 64 bit
Unity 4.6.0f3
but usually runs very smooth and it runs all my dev tools without an issue. VS 2013,Maya, photoshop, Unity,
most of the time I multitask switching between all this apps opened and running at the same time. even with lots of other services running in the background, ie: Ampps web server. and usually my average cpu load idles around 1 to 5 %


Unity Editor usually idles at 0% when not used or play mode.

yesterday while testing beta v2 unity editor idle at 0% cpu before clicking any "Start Server" or "Start Client" buttons when following the getting started tutorial.
then hit any of the buttons and all my cores got maxed up at 100% cpu load making the pc freezing.

now on beta v3 i get similar but now when i hit play button on unity editor before even starting client or server i still get at least 2 cpu all maxed up, then click on Start Server" and still half my cpus maxed, now the weird thing even if i stop the playmode in the unity editor my cpus wont idle as they should but remains maxed up , so i need to close the unity editor completely to remove or stop the cpu maxed up deal by unity .

hopefully this info will help you replicate and find an appropriate fix.


thanks, please keep those betas coming.

 

I just tried the recent beta v3.1 hotfix but still same threading issue as the post above.

cheers

 

I was testing with TCP (couldnt join game with UDP). It does go through an joins the server and loads the right scene, just does not work with instantiated objects.

 

You are the guy who developed Bolt engine! Nice to see you here, I would love the opportunity to share in your knowledge and expertise in the networking field. We are working on new features for V4 of the Beta, we can add you to that release cycle. If you don't mind sending me your email address in a message or to support@beardedmangames.com with the subject "Forge Networking Beta". I would be delighted to know what you think of our system or what we could improve on.

 

We currently have this kind of functionality in the Arbiter (which we will be running an instance of ourselves soon for you guys on a cloud Linux box). Basically one of the Arbiters jobs is to be a MasterServer for server lists. If you check out the current build you have you will notice that there is a fancy "ArbiterServer" class that has a static method "RegisterHost". This will allow servers to register their host ip address and port for easy lookup by clients (i.e: no more needing to type in an ip address and port). You will also see another function for the client to call named "GetHosts" which will get the host list for your querying game/type.

These will not work on your end at the moment, but we will be bringing that simple part of the Arbiter online for testing that before long as it will also be a part of the beta.

However, we can add in network discovery so that we can broadcast to the local network group and find hosts, that would be pretty cool.

 

Brett is taking a look into this issue. When I get home tonight I will look into it as well. We passively test about instantiation on TCP with 3-4 clients on the same machine and port, but haven't tested it in a few days. Whatever it is, we will get it working again tonight!

 

Thank you very much for the thorough feedback! Very interesting, in our tests for V3 we were able to keep the same % load in the unity editor (in play mode) before and after we established a connection. We are unable to replicate it (yet). We are making finding this issue one of the highest priorities.

We will load up the library on a machine similar to your specs (not exact) however we will also fire up a virtual machine and match your specs to see if we can find the issue that way.

We are working on V4 and we plan to keep on rolling out these Beta updates! ;D

 

Thank Farris,

you mentioned before that the arbiter server will be deployed for beta testing soon in a cloud,

does this mean you only going to have could hosted service for the arbiter?
meaning we wont be able to self host it anywhere we want? :-(


thanks

 

Yes i am talking about local network discovery

 

Oh no no no, sorry about making it sound like that! The Arbiter will have a release for EVERYONE. What I meant to say is that I will be hosting an instance of it at it's current state for you guys to test the current Betas to try out the lobby features that are found in the Betas you possess. We will just provide the endpoint for you.

Later we will be releasing the Arbiter for everyone to have their own and not have to rely on us hosting it.

 

Awesome! Yeah we definitely need to add that! I have added this to our feature request/implementation list.

 

i have a question,

the server and the client are 2 different scenes,

the server scene has a script "ServerScene.cs" derivated from SimpleNetworkedMonoBehavior
the client scene has a script "ClientScene.cs"derivated from SimpleNetworkedMonoBehavior

is it possible by RPC when the client press "Space bar" for example, it will call a method with BRPC attribute in the Server script ?

for example ServerScene.cs has a method :

Code (CSharp):

1.  
2.    [BRPC]
3.     private void PlayerSpaceBarPressed()
4.     {
5.        //Do my things
6.     }
7.  

ClientScene.cs has a method

Code (CSharp):

1.  
2.   protected override void Update () {
3.         base.Update();
4.  
5.         if (Input.GetKeyDown(KeyCode.Space))
6.             RPC("PlayerSpaceBarPressed");
7.     }
8.  
9.     [BRPC]
10.     private void PlayerSpaceBarPressed()
11.     {
12.  
13.     }
14.  

For information, it's working with the default Network library of unity, but it seems not working with Forge Networking Beta V3.1

i hope i am clear ...

 

The update should be as follows

Code (CSharp):

1.  protected override void Update () {
2.         base.Update();
3.         if (Input.GetKeyDown(KeyCode.Space))
4.             RPC("PlayerSpaceBarPressed");
5.     }

See if that solves your problem and if not get back to me so we can figure out the next steps to take.

 

Sorry it was the case, the problem still here

 

Okay, lets try this.

I believe from reading your message that the Server script is not calling the RPC but the Client one instead. If you want to call the server you will need to reference the server script in your client as well.

Here is a link to an example video of RPC's so it might give you a better idea of how they work.

http://beardedmanstudios.com/masterclass/beginner/remote-procedure-calls/

Let me know if this works for you.

 

Hi Brent,

I found the issue with "Object reference not set to an instance of an object" issue with calls to Networking.WriteCustom.

I was never calling, Networking.SetPrimarySocket. If you call this, then everything works. Will we always need to set a primary socket?

I have a couple other questions.

1. I want to send traffic via udp and tcp. Do I need to create 2 sockets to do this? And, do the sockets need to be on different ports?

2. I don't always want to broadcast information from the server to all players. How should I:

a) Send data to a specific player. Where player is a NetworkingPlayer, will, Networking.WriteCustom("privatemessage", player.Socket, stream, false); Only send the data to that player?

b) Broadcast data to all players. Where socket, is the PrimarySocket on the server, will Networking.WriteCustom("broadcastmessage", socket, stream, false); Send the data to all players on that socket?

 

It seems the problem is causing by have 2 scripts in my server scene derivated from SimpleNetworkedMonoBehavior.

i have to script one is ServerScene.cs "link" to my camera

Code (CSharp):

1.  
2. public class ServerScene: SimpleNetworkedMonoBehavior
3. {
4.  
5.     // Use this for initialization
6.     protected override void Start()
7.     {
8.         base.Start();
9.     }
10.  
11.     // Update is called once per frame
12.     protected override void Update()
13.     {
14.        base.Update();
15.     }
16.  
17.     [BRPC]
18.     private void PlayerSpaceBarPressed()
19.     {
20.         Debug.Log("Server PlayerSpaceBarPressed called");
21.     }
22. }
23.  

another very simple script is "link" to an object of the scene

Code (CSharp):

1.  
2. public class CubeBehaviourScript : SimpleNetworkedMonoBehavior {
3.  
4.     // Use this for initialization
5.     protected override void Start()
6.     {
7.         base.Start();
8.     }
9.  
10.     // Update is called once per frame
11.     protected override void Update()
12.     {
13.         base.Update();
14.     }
15. }
16.  

in this case the RPC call is not send to the server

If i remove the CubeBehaviourScript.cs file, the RPC call is working

I hope can help you

 

The RPC calls to its own script. As you are in different scenes that don't share these scripts i don't think its possible to achieve what you want to do.

 

You are correct,

This is true due to the objects managing the scene. It may be possible to have a gameobject implement DontDestroyOnLoad from the initial scene so that it is carried from one scene to the other. However this may cause an issue with the management of the object identifiers. This obviously is a feature you wish to have so we will add it to our feature research list!

 

I am glad this is working, however I won't mark this issue as resolved. You should be able to do this action via the reference NetWorker that you already have without the need of using the PrimarySocket.

If you would like to continue your work using the PrimarySocket (which you can assign at any time) then you can continue from here, however I will be looking into resolving the issue of the reference NetWorker not being able to do this functionality. That way you can go back and use the version you wish to use instead of being locked down to the PrimarySocket NetWorker

You will be able to connect both TCP and UDP at the same time with different NetWorkers (which are built on Host and Connect of Networking). In all of our tests we tested around the idea of using different ports for these simultaneous connections. I would recommend using separate ports for these connections. Is there a need for you to have them on the same port?

Since the system is authoritative server by design, only the server manages other players currently. We will be adding a system for players to send a player id for the server to route the message to another player if needed soon though. If the message is sent from the server you have a list of all of the players in the Networker.Players dictionary. We can add a NetworkReceivers argument to the WriteCustom method so that you can specify others, server, etc as well.

Currently Networking.WriteCustom will broadcast the changes to that port (socket) and the server will relay it to the clients that are listening for messages on that same socket. Of course only the clients that have an event registered to process this data will process it (however we will add more targeted messaging controls to this new system).

 

Does this mean we cannot test Client/Server on same machine using UDP? Or, just you can't have multiple clients connecting to the server on the same UDP port on a single machine?

Are the sockets bidirectional? The reason I ask is that I added an AddCustomReadEvent to the clients socket connection with the server, and sent a CustomEvent from the server, but it did not fire the event on the client?
socketUDP.AddCustomDataReadEvent("moveplayer", forgeEvent_MovePlayer);

If they are not bidirectional, does that mean the client has to host a socket for the server to send data to it?

 

I am fine with using different ports. Just in the past I have run both on the same port.

Thats perfect. My current need for this is when a new player joins a game. I need to send them all the current game state data, but I don't want to broadcast to all the other players.

 

Lets say i only want to send messages to some players from the server, if i as an example only wants to update players if they are close enough. Can i then do something like this? (kinda pseudo).

Code (csharp):

1.  
2.             //Testing a player from the server
3.  
4.             List<NetworkingPlayer> list = Networking.Sockets[port].Players;
5.             foreach(NetworkingPlayer p in list)
6.             {
7.                 if(OwnerSocket == p.Socket)
8.                 {
9.                     RPC("ClientUpdate", p.Socket);
10.                 }
11.             }
12.  

I know i only updates the client that actually owns the player in this case. But could i use this method to check through a list of scripts inheriting from SimpleNetworkedMonoBehavior and then go through a loop to only send messages to those where Distance < X... ?

 

Yes, you can currently have 1 server and 1 client on one machine as UDP is not bi-directional. UDP is connection-less so that means that UDP would have a listener on a specified port but no connection to another machine. There are tricks for UDP to have 2 clients on the same port but this means that messages will need to be sent to that port and both clients will get it even if it is only meant for one of the clients.

We are actually working on a system to handle many UDP clients on the same machine and port. However for now it is limited to the 1. If you look in your netstat you will notice that when you connect as a client on the same machine it is actually binding to Port+1 on the client's UDP listener (this is only for when you connect on the same machine). So we added in that temporary magic for testing. If you need to test many on the same computer (until the official fix can come in) TCP will let you do this as it is bi-directional by nature.

Expect the send options (Others, All, Server, etc) to be in V4 build for WriteCustom!

 

Actually, you may be able to "jimmy" something up with this method, however I would much like to support 2 better ways of associating objects to player NetWorker references.

Tonight I will add something like "OwnerId" to SimpleNetworkedMonoBehavior so that you can loop through the players from the server and then do a compare of a each of the player objects in question and comare the Players[j].Uniqueidentifier == obj.OwnerId. With this you will be able to know exactly which player is which object and then update only them with the data based on obj.transform.position.

Also, since we are dealing with games here, I will add the option to store an updated position (Vector3) as a part of NetworkingPlayer. That way when you get the list of Players you will have their latest positions and can easily compare them. Your thoughts?

 

Brilliant
Most importantly document it! But i know you are already doing that.

 

Awesome! Yes, Brett has been working on our initial pass of the auto-gen documentation for the system and is nearly done. We will also make sure to add this one to our list of tutorials that we need to do for the "Intermediate" Masterclass section of the website.

 

Hi all!

I won't be able to make the beta V4 tonight, but will be able to make it tomorrow. There are a lot of performance increases coming to this build. Now that the Beta is getting more mature, we are slowly tightening up the bolts on performance based parts of the system, including lookups, garbage collection, and more. Other things that are coming are:

• OwnerId
• Server stores player position in the NetworkingPlayer
• isPlayer bool for NetworkedMonoBehaviors (which the server uses) for the above tracking

Tomorrow we will be working with the WriteCustom fix for NetWorkers that are not the PrimarySocket, adding the NetworkReceivers enum to the WriteCustom, and some other bug fixes

 

I don't mean to jump on anyone here but these comments about UDP seem... Weird.

I'm not sure what's being said here, UDP is very much bi-directional.

UDP does not have listening sockets at all, otherwise correct.

this is the part which made me react, why not just run the clients on two different ports? You can just bind to port 0 and get a random valid port from the OS. Or if you are talking about the server socket then you would have to explicitly send to each client endpoint, there is no circumstance which will cause UDP to somehow send packets to two remote sockets, unless you explicitly tell it to do so by sending a multicast packet.

 

I had a good play today. I did observe some odd behavior.
1. Unity Cpu process seemed to get stuck on 25% after I stopped the game. I had to kill unity, because it wouldn't shutdown itself. CPU also seemed too high when running the game. Similiar issues as mentioned by GraffixCreation above.
2. I sometimes had to restart unity to get networking going again. Maybe there are some housekeeping issues?

Regarding bidrectional traffic over UDP. I had the client and server sending WriteCustom messages back and forth over the same socket. On the same machine and over a networked machine. It was great, I had my characters walking around each.
However when I tried to connect 2 clients with the server, one client on the server and one client from another networked machine, networking traffic froze up.

Enough of the negative. You guys are doing a fantastic job responding to your Beta testers requests and issues.

I really like Forge Networking. It will make it very easy to implement networking into Unity. As you turn on more features, it is going to become a a very powerful, feature rich system. I love it

 

I had the same problem but the Beta V3.1 hotfix fixed it

 

I rechecked I was using V3.1. I removed all Forge files and re-imported 3.1 package.

For testing I am migrating a project that was using Smartfox. I have my code setup so I can switch between the two networking solutions.

WIth Smartfox, running client & server on same PC uses 15% cpu. With Forge, it uses 69%.

With smartfox, when I stop game, cpu drops to 0%. WIth Forge, it stays at 25% (Always just on one core). After I run the game using Forge, I can't shutdown Unity cleanly, I have to kill the process.

Hopefully firing up the profiler can pinpoint the CPU hog. (I only have Unity Free, so I can't check this out for you).

 

thank god, i am not alone,
Sounds that most developers here are using high end pc hardware that do not feel this to a point of freezing screens.

if you read my past posts seems like you and i are in the same boat.
I thought i was the only one with cpu clogged issues with Forge network.

Farris mentioned they use high end pc dev boxes to develop, 8 cores pc, hence they do not feel the cpu issue,
unfortunately some of us with lower end hardware can feel the cpu freezing in a larger noticeable scale,
in my case 4 core hardware,
beta v2 was a killer for my 4 core box,it just made all my cores 100% clogged that experience freezing on the pc.

beta v3 and 3.1 had a better impact but still clogged half of my cores and even after stopping the play button from the editor, same as you, have to manually kill the unity editor from task manager to prevent cpu clogging.

this should be addressed as some would like to target mid to low end hardware market when releasing their games,
which is my target market for my project.

I hope this gets sorted out soon, i really like to use Forge networking for my project,
otherwise will hate to go back to massivenet, dont want to because it does not support room sessions out of the box other than that massivenet provided all the rest of mmo features needed for my project, and i really need it for the nature of my project minigames pvp battlegrounds matchmaking features so badly need private rooms sessions and Forge networking seems to be covering this out of the box with arbiter server,.

happy saturday.

 

@GraphXCreations, I agree with your comments. Regardless of what spec system you are running, no developer wants inefficient code. Hopefully it is just a gremlin or two they need to work out. They are doing a great job responding to issues, so hopefully we will have a fix soon.

 

UDP is connectionless. That means it is not the "bi-directional" that is being asked about (I assume). It sends a message to IP/Port it doesn't care if it gets there and it doesn't care if there is anything there to read it and it definitely doesn't wait around for a response. So in that sense it is not bidirectional. UDP is simulated to be this form of bidirectional by having two different machines talk back and forth without caring about a connection. They are basically yelling at each other and we write code to make the communication useful.

When I say listens, I mean that it listens for a broadcast on a port, otherwise how would it read anything? You may be taking some too literal on this.

If you read other posts you would have saw me say that we use different ports for this, that is why it works on the same machine for server/client.

You may have taken some of what I have said a little too literal. By broadcast I mean the action of sending messages to an endpoint and not caring if it gets there or not. I am sorry for the confusion. Thank you for keeping me on my toes though!

 

We have actually addressed most of these issues you see last night.

Hopefully with crunching some other bugs you will notice the difference in CPU load as well as now doing great garbage collection. In V4 we hope that this will be a huge change and will help you guys out. Definitely keep letting us know about these issues as we are doing our best to remove anything that would cause problems for you.

Thank you! We hope to make it extremely easy to use and memory efficient. We will look into that issue of having multiple clients on a single server and see if we have not already addressed this issue.

 

We are going to get V4 to you guys this weekend, we are happy to announce we crushed some of the garbage collection issues that you guys are having so this is a more usable network. If there are any problems with this still we are still optimizing and will definitely send out hotfixes as we go for this issue as I have said to a few beta testers that this is our Highest priority.

 

Thank you and in V4 we hope to have solved most of these issues and it is great to have so many people respond to us with their thoughts on what is going wrong. Just as there are so many platforms to be supported, we also need to know how our technology deals with it on our end.

Thank you guys for continously testing it and helping us improve our system, we hope to have all major issues addressed this weekend for the V4 release. If you have any new issues that have not been discussed here, please feel free to let us know so we can add it to our bug lists.

 

Possibly yeah, I read it from the POV of someone that has been doing networking for well.. years by now. And when it comes to stuff like this I find that using the correct terminology is helpful, no matter - you are correct in what you wrote in your reply, we agree

 

I agree, I should probably be more technical in my descriptions. I have been developing networked programs for about 4 years (though more passively in the beginning) and I still talk in broad terms. I think that my main issue is that I am an instructor in Computer Science so I am always talking in terms that make more sense to the viewer as I believe that talking in strict technical terms actually confuse the reader much more than just talking in general terms. Thanks for keeping me on my toes though, I am making a product which does require me to be a bit more technical in what I say

 

Can I poke you about that beta now? ;p

 

Yes, from Beta V1 up to even Beta V4 we are working on optimizing/changing our threading system and yes, it is mostly a house keeping issue more than anything else. We have found and adjusted some of these already. I have no doubt that we will have this fixed by the time we are done with the beta.

Yes, we have mainly tested on a local area network via tablets and mobile phones. We have made some MASSIVE changes during even this Beta which may be causing some of the network traffic issues over the air. Thanks for pointing this out so we can make sure to make it our top priority. We have been working really hard to get as many features into the system that are requested. Performance and bandwidth will always be on our list and we will make sure to make it as good as we possibly can!

We have fixed performance bugs already last night, but we will continue to analyze this problem.