Maybe you missed my point, but I meant that if you're going to go through the trouble of duplicating all of Construct's helpful events and what not into python, why not just write everything from scratch to begin with?
There are so many events that need not be duplicated into the server. My game is just a graphical representation of some maths. (For example, Player 1 shoots player 2 and does 20 damage each second. The server will take 20hp from player2 each second, however on the client screen it will appear to be an epic battle with thousands of bullets or whatever. Another example is shooting a missile. The server will decide whether it hits and how much damage it will do and roughly how long it will take to hit player 2. However on the game screen the missile will fly and curve around etc.)
I won't have any physics. Interpolation is done client side (ofc) and If I choose to trust the client with his own movement, i'll have the server check if his movements are in the realm of possibility and disconnect him if not.
[quote:q6aizjtt]
....,647. Try to imagine how long it would take to exceed that. At 10,000 connections a day, which ain't bad for most websites, that's 214,748 days until that number fills up. Or 588 years. Of course a malicious user who writes a connect/disconnect bot will make your server throw an exception rapidly.
Secondly, and probably more realistically, you should be using a guid. In which case, the concern isn't really valid to begin with. If you're going to send 4-8 bytes anyway, it may as well be a unique identifier. This might lend some security as well, if you use the first method and only that, objects will always be the same ID, which could give sniffers an advantage (hard to imagine how, but scripting would be much easier).
This is exactly what I was talking about. I don't want the list to ever "fill up", it has to be robust so it cannot be exploited in this way. I figure when clients disconnect i'll just replace them in the list with "empty", then when a new client connects it either goes in the earliest empty slot, or if there are no empty slots, we'll add him to the end of the list.
Why exactly is it necessary to use a GUID/UUID? These IDs are only there so we can pick the correct player to update positions of on the client when we receive new movement vectors etc. I don't see why it needs to be anything other that just a short,simple value?
[quote:q6aizjtt]
Well, PodSixNet is a connection based library... You'd just send directly to their connection. You might organize that into a set of containers (channels, for example), in which case, if you just want to talk directly to clients you could keep a "master" copy container (dictionary) for convenience. If I recall, that's how the author of PodSix does it, although he uses WeakRef (which is probably cleaner at the end of the day).
Try not to overthink it too much, in most cases, you'll be sending a response to the client directly so you'll know which channel to reply to at the moment of receiving their request (try to think of an event-based networking system -- this is how WoW does it).
Ok this is fine. So basically PodSixNet doesn't handle any of that for you. We have to make our own "channel" system using a dictionary etc.
As to the response based communication. What about in WoW in the case of DOTs (damage over time attacks) for example. The server needs to keep updating the health of the victim even when there is no "event". Perhaps I misunderstand this part? But in these cases, the server will need to send updates to the clients of their health/damage done etc. even when there is no event or packet sent to the server from the client.
Thanks a lot for the help so far man! Hope i don't sound like I'm arguing, I often find challenging something I don't understand is the easiest way of understanding it