Added missing ENUM, and packet source IP identification

[ntbutler87]

enum.py - Added the missing "REPLAY_WATCHING" item from GameState

stream.py - Changed the socket receive function to allow the identification of the IP sending the multicast packets - useful for LAN party. There's probably a better way to handle this so others wouldn't need to necessarily change their handlePacket methods..?

[coveralls]

Coverage increased (+0.05%) to 88.841% when pulling c43fc503118d22093d65c343689914fb32323d06 on ntbutler87:master into 0eba3169360bd120f69bd7c53e658a05057415e6 on jamesremuscat:master.

[jamesremuscat]

Thanks for the PR.

Just to clarify - the issue here is multiple copies of the game running on the same network and all broadcasting state packets?

Rather than change the signature of handlePacket, what I'd do is add an optional host parameter to the constructor of PCarsStreamReceiver: if specified, then it will only call handlePacket for packets from that host.

That means:

• we maintain backwards compatibility
• we don't require users of the library (or software built from it) to know and configure the IP address of the machine running the game ahead of time
• we allow (but don't require) users of the library to filter packets by IP.

What that doesn't allow, which your initial solution does, is the ability for one PCarsStreamReceiver to be used to receive the state of multiple running copies of the game (which may or may not be in the same lobby). I'm not sure if that's a compelling use-case though.

What are your thoughts?

[ntbutler87]

In my particular instance, the modifications made are specifically to ensure that we are receiving traffic from only 1 desired host when multiple copies are running on the same local network.

At this stage anyway, I don't have a use for being able to capture packets from multiple hosts with the one PCarsStreamReceiver. I would imagine that a better solution for that case would be multiple PCarsStreamReceiver's initiated with their own desired host parameter.

Others in the future may want this functionality for a particular use case, but your proposed solution would certainly work for most cases in my mind.