I need a little advice with deploying Triton inference server with explicit model control. From the looks of it, this mode gives the user the most control to which model goes live. But the problem I’m not able to solve is how to load models in case the server goes down in production which triggers a new instance to spawn up.
The only solution I can think of is to have a service poll the server at regular time intervals, constantly check if my live models are actually live and if not, load them. But this seems like quite a complicated process.
I would like to know how others have solved this problem.
Thanks in advance
Related
I'm trying to understand how to call events between client and server. My goal for now is simple. I want to create anything that is interactable for 2 players.
Easiest thing I could think of was cube that is switching color when clicked. So I did create actor based blueprint, checked "Replicates" and AlwaysRelevant to be sure. PlayerController is also replicated and there is no pawn needed.
Color change blueprint:
SM is just static mesh if that is important. As far as I know client have no authority to call multicast events so I wanted to push it through server but it stops there. Called from server works as expected and color itself IS replicated to client, however client cannot change color himself.
What am I missing in this concept? I've watched like 5 videos about replication and I started to think there is something missing which is either obvious for everyone but me or their examples do not need things I do here.
As you've found out, a player's client can not directly call server RPCs on actors which the player does not own. Calls must be routed through that player's PlayerController. The server copy of the player's PlayerController can then call server methods on server-owned actors.
Another issue is that you seem to be using both RPCs and replicated properties for the same purpose. Unclear to me why changed is replicated since you're modifying it in a multicast event which normally runs on all the machines. This is a recipe for hard to find race condition bugs.
Replication in Unreal is definitely one of the harder concepts to get the hang of. The resource that helped me the most is this guide which while quite dated, is both comprehensive and to the point.
You can't have it in PlayerController, it's got to be in a Pawn, or if not, in PlayerState, or it won't get shared to other clients.
I have built and started an OPC UA embedded Openmodelica server with the BouncingBall model like so:
$ omc +s path/to/model
$ ./BouncingBall -embeddedServer=opc-ua -rt=1
Now I'm trying to interact with it using an OPCUA client. However, I don't understand how I'm supposed to interact with the server properly. As far as I know this is undocumented.
The most promising approach seems to be to set enableStopTime to false and run to true. Then the simulation seems to run indefinitely and the values seem to make sense. It seems I'm only able to extract the values in real time however. While running, when I set run to false it seems that the server enters an erroneous state and it refuses to give any values back.
If I restart the executable and instead set step to true nothing seems to change and after trying to set step to true a second time the server becomes unresponsive. The -rt=1 option doesn't seem to matter. Seems like it enters the same state as above (1).
(After restart) If I leave enableStopTime to be true and set run to true the simulation runs to stop and then the server quits with message The simulation finished successfully. Maybe this is intended. Kind of seems odd. Would make sense to be able to restart the simulation or trigger it with new options.
What I would hope to be able to do: Start and stop simulation as well as rewind to a certain point to check the value at that point. It seems to me that the API "affords" this functionality and it could probably be provided by hackingly wrapping the executable and API. Are the above bugs or intended? What is the intended way to interact with an OPC UA server in these cases?
The OpenModelica compiler version is 1.16.0~1-g84b4a71
Please try the latest nightly build
It includes the following commit.
That might solve it. I believe things worked without subscriptions before, since I could never reproduce this without them.
(By the way, do people go on our git commit feed and try to reproduce bugs fixed in the last 24 hours; we quite often get questions that were just recently fixed)
I'm using the old Unity 2017.3 UNET implementation in my game. Players connect to a server and are placed in a Lobby scene until the party leader selects another level to go to. The implementation is just a slightly modified version of the default NetworkLobbyManager.
The trouble started now that I've begun heavily testing the networking code by running a compiled build for a client and then using the editor as the server. Very frequently, the server running in the editor will run a great deal slower than the compiled client build. So when I use NetworkManager.ServerChangeScene the client will load the scene before the server, which will cause all NetworkIdentities on the client scene to be disabled (because they haven't been created on the server yet.)
It's a lot less likely to happen if the server is running a compiled build, because the server will almost always load the scene before any clients. But it does surface a bigger issue with Unity itself. That there's no guarantee that the server will be available when changing scenes.
Is there some other way of changing scenes in a networked game? Is there a way to guarantee that the server enters the scene before any clients? Or am I stuck just kind of hoping that the network remains stable between scene changes?
Well I thought about it more overnight and decided to look in other directions, because more investigation revealed that sometimes the Network Identities are still disabled when the server loads the scene first as well.
I was looking through the UNET source code and realized that the server should be accounting for situations where it loads the scene after the clients, although that code looks a little jank to me. This theory was backed up by the documentation I found that also says NetworkIdentities in the Scene on startup are treated as if they are spawned dynamically when the server starts.
Knowing those things now, I'm starting to think that I'm just dumb and messed some stuff up on my end. The object that was being disabled is a manager that enables and disables other NetworkIdentity objects. I'm pretty sure the main problem is that it's disabling a network identity on the client, that is still enabled on the server, which is causing the whole thing to go haywire.
In the future, I'm just going to try and stay away from enabling and disabling game objects on a networked basis and stick to putting relevant functionality behind a flag of my own so that I can "soft disable" an object without bugging out any incoming RPCs or SyncVar data.
I have a multiplayer project which has some forever loops with checking code inside of them.
The problem is, multiple computers might process this and change crabx or craby due to lag in the variables dvotes, uvotes, lvotes, or rvotes. Only one machine should change this, though.
This can be easily solved by giving each player an ID like many people do in SQL. I would just check if the ID is 1, and that would be the "operating machine". I would then do all of these checks on that one machine. It would do things a Scratch server would do if you could program it...
The problem with this is that there is no way to detect when a player leaves the game. There is no block that is called "on exit" or "on stop button pressed". How would I go about doing this? I have seen people have a button which people click to exit, but some people will not click it/not even see it.
Thanks in advance!
Option 1
I've never been especially successful with cloud data myself, but I've heard the theory on this before:
Essentially, each player gets a "counter". Their computer then constantly increases that counter. If the counter ever stops increasing (which will be detected by the other computers, who are all looking after one another), the project will know that the user has left and one of the computers will take care of removing their ID and other data.
Obviously, this is much easier said than done. (As I said, I've never gotten complex cloud data to work well for myself, but I've seen it done successfully and explained.)
Option 2
Alternatively, you might be better off taking advantage of this cloud api created by MegaApuTurkUltra. I find that stealing from others tends to be the best way of solving problems when it comes to code. ;)
I have an application (Laravel + MongoDB running on Nginx) where I pull some data from the database and render it on the screen. The application focusses on multiple real life objects. Once an object is turned on (is_on equals to true in the database), the timer on the screen needs to start ticking. Once the object is turned off (is_on equals to false in the database) the clock stops ticking and resets to 0. The format of the clock is HH:MM:SS. So it shows how long the real life object is turned on.
My problem is that I don't really now how to save/implement such timer. When the user request the page, I pull the necessary data from the database. If I also save the timer in the database, you have to make a query every second which is very bad practice.
I remembered something about WebSockets and tried to look into them. I actually managed to build a basic Hello World chat application, but don't really know how to implement this in my project. There is no place for it in the database (because of the queries), so I don't really know where to save that timer on the server. I'm also doubting if WebSockets are the way to go.
So are WebSockets the way to go and if it is, can you guys point me in the right direction on how to implement this? If not, can you advise me what I should do?
Thanks in advance!
From your question:
I understand that the objects you print in the screen are modified by
users in the application, and your aim is to live forward those
modifications to other active client instances of your application.
In that case, as you mention, I would point you to websockets. They are a great way to feed information directly to the client, so the client receives the update signals and modify the interface, with no need of user action.
In order to implement the logic to notify the client, I recommend using a push approach, but this is really depending on what kind of clients you'd like to notify, since the push world is still a bit tricky.
Further readings for this websocket based push implementation:
Question about Push Flags:
Difference between push and urgent flags in TCP
If your client runs in browser or mobile this question is nice to read:
How to send push notification to web browser?
Also html5 websockets:
http://www.websocket.org/aboutwebsocket.html
As a sidenote:
A nice architecture for client-server live communication is based on node.js together with socket.io library offering good performance and not really complex implementation if you know what you do.