In Halo 1 for PC, you could open Multiplayer and search for locally hosted servers. In many other modern games you can do this too. How is this possible?
It's likely these games:
Send broadcasts ("is anyone out there?") and wait for answers
Send multicasts and wait for answers (see above)
Wait for others to shout ("Hey, I'm a server") via broadcasts / multicast
Broadcasts and multicasts are propagated in the entire local network.
In simple terms, they broadcast a message over LAN. Locally hosted servers respond with an "I'm an available server!" message. Computers that are not running instances of the game server simply ignore the request.
Related
I am making a multiplayer game that is UDP with node.js (dgram for UDP) and unity as the client (uses c#'s sockets). I originally had a web-socket server, but remade it to be UDP for more competitive response times.
It works perfectly at my house and between my and my friends, but when I try it at school it doesn't work (both LAN and WAN). With non-local hosting nothing works (expected because my school has a whitelist), but with LAN (not localhost) The client sends and initial join packet (exactly the same way of sending as everything else) but then just doesn't send any more packets. My server logs the join message but then the client gets timed out from not sending any more messages after that.
Additionally, the client freezes during the second message and has to be shut down from task manager, which gives me the idea that it's message is being blocked over the network.
Is there a way around my school wifi blocking my server messages, and if there isn't what should I ask my school's tech person for (probably won't work but worth a shot)
Thanks in advance (:
Well, there is nothing you can do to solve certain situations like this by bypassing alone.
If your school remotely controls what protocols (TCP, UDP) that is allowed or blocked, it is better and the right thing to ask them to lift the ban up for traffic between UDP connections.
Also, the firewall can be the main one to blame. By default, many firewalls block UDP traffic because essentially, it is an unsolicited network traffic and may be used to do malicious exploitation since it doesn't care whether or not it has the server's permission to communicated in between and it can't do it doesn't support ACK (Can even cause DDOS in that manner).
More information and references about UDP: Link
However it is more of an overstatement but know that firewall in general do block all incoming traffics by default. TCP is usually accepted, and maybe your school blocked all UDP connections because of the details said above.
Hellow, i'm working with network programing and it's been so hard to create a logic that allows to stream a video from a single server to multiple clients with no delay.
which means that i have to implement a parallel execution during the stream to all connected clients in order to display the images at the same time.
and why is that important for my project it's because i'm intending to have large number of clients (from 200 to approximately 700), now with 10 clients that delay is nothing but with 700 clients could significantly increase the delay to several minutes (not sure but possible).
for those who don't know what's the cause of the dely, it's from the for loop that i'm using which contain the send function for each frame, and that is a serial execution.
i tried threading and multiprocessing and even function schedule but every thing got messy, previously i was using socket & opencv, but for some reason it caused issues during the streaming, now i switched to Netgear & Vidgear but i'm still struggling.
Hope someone can help.
PS: multicast is just not right for the job, after i tried it i was receiving errors because of the length of the transmitted images, UDP protocol will NOT accept more then 65535 byte.
Per your comment, everything is in the same network, and we have multicast for exactly your problem. Rather than sending the same data over and over to multiple hosts, you can send a single stream of traffic to many receivers.
You set up the clients to subscribe to a multicast group, normally a group in the 239.0.0.0/8 Organization-Local scope. Your server then sends its traffic to the same multicast group to which the clients have subscribed. The single traffic stream will be received and processed by every client subscribed to the multicast group.
Because multicast sends to multiple clients, you must use a connectionless transport protocol, e.g. UDP. Connection-oriented transport protocols, e.g. TCP, create connections between two hosts, so they cannot be used with multicast, which is one-to-many.
By default, multicast only works in the same network. We do have multicast routing to send traffic to other networks, but it is very different than the usual unicast routing. Also, you cannot multicast on the public Internet because the ISPs do not have multicast routing. You can multicast to a different site across the Internet by using a tunnel that supports multicast, e.g. GRE. Both the source and destination routers need to be configured for multicast routing, as well as any routers in the path of the multicast packets (the Internet routers on see the unicast tunnel packets, not the multicast packets, so you can send the multicast across the Internet).
Hellow, i'm working with network programing and it's been so hard to create a logic that allows to stream a video from a single server to multiple clients with no delay.
Hey #zaki-lazhari I'm the creator of VidGear Video Processing Python Project. Actually, NetGear is not right API choice for multi-casting task, instead you should be using WebGear API. WebGear can acts as powerful Video Streaming Server that transfers live video-frames to any web browser on a network. So you can easily setup WebGear Server in few lines of code as follows:
# import required libraries
import uvicorn
from vidgear.gears.asyncio import WebGear
#various performance tweaks
options={"frame_size_reduction": 40, "frame_jpeg_quality": 80, "frame_jpeg_optimize": True, "frame_jpeg_progressive": False}
#initialize WebGear app
web=WebGear(source="foo.mp4", logging=True, **options)
#run this app on Uvicorn server at address http://0.0.0.0:8000/
uvicorn.run(web(), host='0.0.0.0', port=8000)
#close app safely
web.shutdown()
So every device (even a smartphone with any browser installed) on the same network can access real-time frames on there browser without any extra dependencies. More code samples can be found here: https://abhitronix.github.io/vidgear/gears/webgear/advanced/
Hope it helps. Good luck!
I'm building a fast paced webgl game and as a common problem I'm experiencing is the retransmits of lost TCP(websockets) packets on higher packet send / receive frequency.
Two options I considered:
1. using webrtc with node.js client to simulate node.js as a peer and connect it to browser for UDP use. So far unsuccessful to connect it to heroku, though works great locally. Is this possible, are there any limitations I overlooked which made it impossible for me to implement into heroku?
2. using multiple websocket connections from single client to a single user on server. Server & client would discard those messages that come from an older tcp packet (let's say 30-60ms delay due to retrasmits). Therefore making it seems like it's a UDP connection. Is this valid, would those connections break each other or work independantly, are there other really bad drawbacks to this method ? This would be an easier alternative to implement.
The reason I would not like to connect two clients via webrtc, but rather need it to connect to server is security. Thanks in advance.
I have one server and multiple clients. The server wants to run shell script on each device it wants to. Absolutely it's not possible via simple socket because we may have thousands of devices. Also server and devices should be always connected via socket. after a lot of search I found out that the solution might be NAT-T. But still I don't know how to use that or if there is another solution.
Please help me what should I do on clients and server.
If you don't know the clients address and port upfront, you need to connect to the server with the clients. 1000s of devices are no problem. You run in a socket limit around 65000 open ports (check ulimit). Build an object stream between client and server and execute the script based on the object the client receives. You could also set an interval on the clients and let them check with simple http(s) every n secs if there is something to do for them?
See for example here: Node Stream Docs
Or here: Node HTTP Docs
I'm developing chat application using app.js which is webkit+node.js framework.
So i have node.js plus bridged web browser environment on both sides.
I want to make file transfer feature somewhat similar to Skype one.
So, initial idea is to:
1.connect clients to main server.
2.Each client gets ip of oposite ones.
3.Start socket or websocket server on both clients and connect to each other.
4.Sender reads the file and transmits it to the reciver.
Question are:
1.Im not really sure that one client can "see" the other.
2.file is a binary data, but websockets are made for text messages so i need some kind of coding/decoding stuff. I thought about base 64 but it has 30% of "overhead" information. So i need something more effitient (base 128?).
3.If it is not efficient to use websocket should i use TCP sockets instead? What problems can appear if i decide to use them?
Yeah i know about node2node and BinaryJS, i just dont know should i use them or not. And i really what to do something myself.
OK, with your communication looking like this:
(C->N)<->N<->(N->C)
(...) is installed on one client's machine. N's are node servers, C's are web clients.
This is out of your control. Some file sharing apps send test packets from the central server to clients, to check whether ports are open and NAT rules are configured correctly, etc. Your clients will start their own servers on some port, your master server can potentially create a test connection to these servers to see whether they're started correctly and open to the web, BEFORE telling other clients that they can send files.
Websockets are great for status messages from your servers to the web GUIs and general client-to-client communication. For the actual file transfers, I would use TCP sockets, see the next answer. On the other hand base64 encoding is really not a slow process, play with it and benchmark its performance, then decide with some data to back up your decision.
You could use a combination: websockets from your servers to the web GUIs, but TCP communication between the servers themselves. TCP servers (and streams) aren't hard to set up in Node, I see no disadvantages. It might actually be less complicated than installing node2node on those servers, since TCP is already built-in.