I need to make many http request per second and am wondering what the best way of approaching this would be.
I am familiar with keep-alive, but with limited experience and the docs being light on the subject, I am unsure what the best practices and conventions are for working with real-time dynamic data.
Any guidance and/or code snippets to get me started would be appreciated.
I’ve done many GET requests using a for loop, but you might need to explain a little bit more about what you’re doing.
To proof the concept I want to be able click and start making continuous calls to GET the updated data many times per second (15-30) and keep running till I tell it otherwise.
I don’t think you should be using HTTP for such kind of things. HTTP is not really performant. You need some networking solution where a server would send you a message whenever data changes, rather than client poking for it all the time.
Unfortunately that is not an option for me. Thinking an IEnumerator with a while loop may be the way to go for the poc for now.
I used webrequests. It’s doable….but why so many and constantly? You tapping a weather API or something?
I’m not following what you’re asking here…
If you want to do a proof-of-concept, do it. Like we’re talking all of 5-10 lines of code to test what you considered as a possible option.
Otherwise… if you want our opinion on it… well, we need more information. What is the server? Why must it be http? Why the frequency? What are your limitations?
Without this extended information you’re going to get people suggesting things that don’t fit your needs… like has already happened. Which is just time wasting for all parties, yourself included. Especially when your proof-of-concept should take you less time to test than it would for any of us to read and reply to your post.
Unless that is you were hoping one of us would post the code that is your theorized proof-of-concept… in which case, why not just ask that?
…
Note - I doubt you’re going to consistently get the number of requests you want. If I know UnityWebRequest, which I do, it can be way slower than the 66 millisecond minimum response time you’re looking for, let alone the 33ms optimal response (30 per second). Nevermind that speed of the server, current traffic on the server, and the speed of the user’s network/device all play roles in what is already a high latency situation. I won’t be surprised if a simple one word response message will still be like 5-10 per second max… or basically 200ms response time.
Just to give you an idea… I just ran a ping against google.com over my gigabit fiber internet on a gigabit hardwired network connection in my hosue.
A raw ping alone averaged 10ms for me. That does not include the actual GET message, the time on the server to process the GET message, the time on my client for unity to unwrap the response, nor the time for unity to synchronize this async method back onto the main thread for the coroutine to complete its yield.
WebSockets (SignalR) might be a better solution for you. Check it out.
Apologies for your time waste, I appreciate the notes, those actually help provide additional context that is outside of my expertise, so I feel there is no time wasted here … Also, I am not looking for someone to just write code for me, if you check my original post, I did ask for code snippets.
I’m was just trying to find a performant/conventional way to get as close to real-time as possible with http requests, solely due to my client wanting a PoC using http. I can get close by throwing the request in Update(), but feel that is overkill and not actually successful each call, IEnumeration to delay those calls producing a more fluid simulation. But, is this bad practice? I think it may be …
I will end up using websockets, for the final product, but again wanted to proof something out per request, so I was hoping to hear some conventions, guided to better documentation, and possible code snippets for a continuous http connection (keep-alive ?) to a local server to represent real-time data visually in Unity.
Yes, WebSockets is the way to go for real-time server to client communication (“push” model) over HTTP (although HTTP is used only at the beginning for doing a “Handshake”, then transparently switched to direct TCP). Microsoft’s SignalR makes it a breeze, and there are tons of tutorials on it.
Polling the server is totally inefficient for both the client and the server. Just imagine having 20, 30, 50… clients polling the server several times a second all at the same time, they’ll bring the server down, as you’re just… DDoS’ing your own server…
SignalR/WebSockets on the other hand, opens one connection and keeps it open for the whole time, enabling very fast bidirectional communication, as the Server will only send data when it’s needed.