I am working on a small programming game/environment in Python to help my younger brother learn to code. It needs to operate over a network, and I am new to network programming. I am going to explain the concept of the game so that someone can point me in the best direction.
The idea is a simple grid of 25x25 'diodes,' squares with fixed positions and editable color values, essentially simulating a very small screen. In addition to the grid display, there is a command window, where Python code can be entered and sent to an instance of InteractiveConsole, and a chat window. A client needs to be able to send Python commands to the host, which will run the code, and then receive the output in the form of a string representing changes to the grid. My concept for doing this involves maintaining a queue on the host side of incoming and outgoing events to handle and relay to the clients on individual threads. Any given command/chat event will be sent to the host and relayed to all clients, including the client who created the event, so that those events are visible to all clients in their command/chat windows. All changes to the grid will originate with the host as a result of processing commands originated from clients and will also be sent out to all clients.
What I primarily don't understand is how to synchronize between all clients, i.e. how to know when a given item in the queue has been successfully sent out to all clients before clearing it from the queue, since any individual thread doing so prematurely will prevent the item from being sent to other clients. This is an extremely open-ended question because I understand that I will definitely need to consume some learning materials before I'm ready to implement this. I'm not asking for a specific solution but rather for some guidance on what general type of solution could work in my situation. I'm doing this in my spare time, so I don't want to spend a month going through networking tutorials that aren't pointing me in a direction that will be applicable to this project.
My approach would be to use a udp server that can broadcast to multiple clients. So basically, all the clients would connect to this server during a game session, and the server would broadcast the game state to the clients as it is updated. Since your game is relatively simple this approach would give you real time updates.
Related
I’m working on a project involving websockets using python-socketio.
Our primary concern is fluidity, each connected user will have a cursor whose position on the board is sent as event every 50ms, boards are identified as (socket) rooms, and we are expecting many of these.
I’m new to PubSub, we are horizontally scaling our architecture and it seems to be the fit for events broadcasting.
I had a look at AsyncRedisManager class and from my understanding, it seems any message, sent by any socket on any socketio server (with pub/sub) is then transmitted / published from this server to redis on a single channel of communication. Subscribers to this channel can then see this flow of messages.
I’m hence concerned about 3 things:
Since all messages are simply going through one channel, isn’t this a “design flaw” as some servers might have no sockets connected to “one” specific room (at the moment), still they will be receiving (and pickle.loading), messages they don’t care about at that time.
The actual details of these messages (room, payload, etc.) is pickled.dumped and pickle.loaded by servers. In case of 50 rooms with 50 cursors each sending 25 event/s, isn’t this gonna be a huge CPU-bound bottleneck ?
I’m wrapping my head around the socket.io docs, comparing side by side the redis adapter to Python-socketio pubsub manager, and it seems channels are dynamically namespaced like “socketio#room_name” and messages broadcasted to these “namespaced” channels so that psubscribe would be a viable solution. Some other MQ refer in the terms of “topics”.
if the former assumption, is correct, still we cannot assume whether one server should or should not psubscribe to a channel#room_name unless no or at least one socket for that server is in the room.
I understand the paradigm of pub/sub is, from Redis page:
Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more channels, and only receive messages that are of interest, without knowledge of what (if any) publishers there are.
But my question would be summarized as:
is it possible to make Python-socketio servers dynamically subscribe/unsubscribe to channels whenever there is a need for it, with channels identified as rooms, hence having as many channels as rooms in total. Would that be feasible while keeping this “plug-&-play” simple logic as a pubsubManager subclass? Am I missing something or does this make sense ?
Thank you for your time, any ideas, corrections, or “draft” code would be greatly appreciated.
is it possible to make Python-socketio servers dynamically subscribe/unsubscribe to channels whenever there is a need for it, with channels identified as rooms
I guess it is possible, with a custom client manager class. You would need to inherit from one of the existing client managers or the base client manager and implement a different pub/sub logic that fits your needs. But keep in mind that if you have 10,000 clients, there's going to be at least 10,000 rooms, since each clients gets a personal room.
I am trying to create a multiplayer game for iPhone(cocos2d), which is almost finished, but the multiplayer part is left. I have searched the web for two days now, and can´t find any thing that answers my question.
I have created a search room(tcp socket on port 2000) that matches players that searches for a quick match to play. After two players has been matched, that server disconnects them from the search room to leave space for incoming searchers(clients/players)
Now I´m wondering how to create the play room(where two players interact and play)?
I was thinking I could create a new tcp/udp socket on a new port and let the matched(matched in the search room) players connect to that socket and then have a perfect isolated room for the two to interact with each another.
Or do I need a new server (machine/hardware) and than create a new socket on that one and let the peered players connect to it.
Or maybe there is another way of doing this.
OBS. I am not going to have the game running on the server to deal with cheaters for now. Because this will be to much load for the server cpu on my setup.
I was thinking I could create a new tcp/udp socket on a new port and let the matched(matched in the search room) players connect to that socket and then have a perfect isolated room for the two to interact with each another.
Yes, you can do that. And there shouldn't be anything hard about it at all. You just bind a socket on the first available port, pass that port to the two players, and wait for them to connect. If you're worried about hackers swooping in by, e.g., portscanning for new ports opening up, there are ways to deal with that, but given that you're not attempting any cheap protection I doubt it's an issue.
Or do I need a new server (machine/hardware) and than create a new socket on that one and let the peered players connect to it.
Why would you need that? What could it do for you? Sure, it could take some load off the first server, but there are plenty of ways you could load-balance if that's the issue; doing it asymmetrically like this tends to lead to one server at 100% while the other one's at 5%…
Or maybe there is another way of doing this.
One obvious way is to not do anything. Just let them keeping talking to the same port they're already talking to, just attach a different handler (or a different state in the client state machine, or whatever; you haven't given us any clue how you're implementing your server). I don't know what you think you're getting out of "perfect isolation". But even if you want it to be a different process, you can just migrate the two client sockets over to the other process; there's no reason to make them connect to a new port.
Another way to do it is to get the server out of the way entirely—STUN or hole-punch them together and let them P2P the game protocol.
Anything in between those two extremes doesn't seem worth doing, unless you have some constraints you haven't explained.
OBS. I am not going to have the game running on the server to deal with cheaters for now. Because this will be to much load for the server cpu on my setup.
I'm guessing that if putting even minimal game logic on the server for cheat protection is too expensive, spinning off a separate process for every pair of clients may also be too expensive. Another reason not to do it.
I have a program that sniffs network data and stores it in a database using pcapy (based on this). I need to make the data available in realtime over a network connection.
Right now when i run the program it will start a second thread for the sniffer and a Twisted server on the main thread, however i have no idea how to get clients to 'tap into' the sniffer that's running in the background.
The end result should be that a client enters an url and the connection will be kept open until the client disconnects (even when there's nothing to send), whenever the server has network activity the sniffer will sniff it and send it to the clients.
I'm a beginner with Python so i'm quite overwhelmed so if anyone could point me in the right direction it would be greatly appreciated.
Without more information (a simple code sample that doesn't work as you expect, perhaps) it's tough to give a thorough answer.
However, here are two pointers which may help you:
Twisted Pair, a (unfortunately very rudimentary and poorly documented) low-level/raw sockets networking library within Twisted itself, which may be able to implement the packet capture directly in a Twisted-friendly way, or
The recently-released Crochet, which will allow you to manage the background Twisted thread and its interactions with your pcapy-based capture code.
I'm working on a game (Risk). I've already finished set-up, so a solution that doesn't require me to completely redesign networking would be preferable. The problem is I've gotten to main gameplay, and I need to allow messages from multiple users at the same time. The general idea is that when one player is taking their turn, another player can send a forfeit message, and still exit out of the game without crashing the whole server. Is there a way to do this, possibly using threading?
There is no reason that your main thread should be blocked on one connection.
You need one listening thread, when a connection is made background threads handle communications to clients.
You do need to maintian a bullet proof state machine so that clients know the appropriate messages they can send at any given state, and the server needs to know which valid messages can be processed at any given state.
Search stackoverflow, you'll find many examples, such as this:
Sockets example
I have a very big problem and i want help in solving them problem. I have a real server on my desktop and all my class mate can connect to it. But i want a way of recieving data from one client and sharing it to other clients and vise versa with out any other Interface or data modification. Currently if if many clients send message every thing is messed up the data sent to each other becomes like this: "howarecomebackletscome23jf". So message is packed on top of messsage even though clients are typing. What i can do to make sure than every clients messags either while typing is not modified....