mondego / rcat Goto Github PK

Each user should have a personal workspace where they can (UNDER DISCUSSION) lock pieces for themselves, and work on creating and blogs.
Discussion: Should that workbench be a shared space or individual?

In src/data/mappers.
If data is remote, obm sends msg to owner to delete. If local, delete locally.

Verify if updating objects remotely works as expected. Still untested (so probably no)

Need to write test cases for testing remote updates, object relocations, etc.

Includes:

• message type for game over
• message type for game init
• or a single message type "game over; here's the new config"?

Best candidates: pssh, sdh, gsh, cluster-ssh
Expect can also be used for this purpose.
http://superuser.com/questions/252218/how-can-i-broadcast-to-multiple-ssh-using-file-descriptor

When I reload it with F5 it works, but the first time opening jigsaw.html with Chromium always cause it to throw that error. The background seems to load fine,but not pieces show up on the board.
Marking Thomas, but I'll look into it!

The data connector is monolithic in the file mysqlconn.py. It assumes multiple roles, which we broke down into:

1. Mapper: Provides mapping between an input value to objects. Commonly an ID is used, but in space partitioning a range is used instead
2. OBM: Provides communication between data nodes and organizes object ownership, marking on the database when it owns or lets go of objects.
3. DB: Provides functionality to write to the database.

To achieve this purpose, I propose to add new packages in the data module:
db: resides database connectors. mysql is the only database as of now
mappers: provides classes that implements mappings of the any sort. Currently, we have space partitioning and the chat manager style
plugins: Additional modules that increment functionality. Pubsub for IDs is a plugin, so is the OBM

Additionally, I propose the creation of the abstract class DataConnector and Mapper. Mapper sets necessary methods for any mapper, data connector just gathers all the components in one container (not sure if I need it for anything though).
The app logic should instantiate the pieces and build the Data Connector as it desires.

PS: Will add image later

Allow players to play against each other. Possible design might include something similar to Quadra: upon placing a a certain blob on the board, the other player placed pieces get taken off the board, or remain in the same place but mixed. Other ideas are welcome on the comments

Allow players to put pieces together outside of the board and form bigger pieces.

That's a bug. When f5 after reloading the server, the pieces don't always show up.

Many of the plugins are interested in insert, select and other data events that are sent by the client. An event manager would correctly distribute events to interested plugins so they can perform their part

Includes bot?

List micro-benchmarks

• greenlet vs stackless vs normal python
• client: single-threaded a la Tornado vs multi-thread like the current java one

Client should update the server 5 times per second when moving pieces

While the image is downloading, perform all the work necessary to start up the game.

As described, implement player name input and keep scores for pieces placed per user.

Create a python bot that will connect and interact with pieces in-game

Not sure if duplicate of #34 or not, only happens when I put it in the correct place and it binds. Doesn't affect game play, still works, so minor thing..

Error:
Uncaught TypeError: Cannot set property 'x' of undefined
Model.dropRemotePiecejigsaw-model.js:247
Network.socket.onmessage

Even the 6 siblings on the rack!

When a client clicks on a piece, it should send a lock request to the server that should remain locked until it is dropped

Goal: select all the pieces when a client just connected.

Right now, it's just dumping datacon.db.tables['tableName']

Should happen on the server-side; the server sends a "piece bound msg" to everyone, containing the piece id and the id of the player who dropped the piece

Convert the "glued" snippets to an understandable MVC pattern.

Zoom in and out on mouse point
Drag screen
Drag pieces
Pieces Magnet to board when place correctly
Drag border limits

Pushed for a later sprint. Remember to solve concurrency issues!

Maybe use 't' to toggle, or space maybe?

Right now, when in a corner and dragging towards that corner, the frustum is sent again with the same (and correct) value. This sending is superfluous.

When a server drops, allow it to recover the piece data from the database and restart. The only way to clean the board now is to actively query a drop table or delete from jigsaw in the mysql db.

Initial data structure used will be a bucketing matrix with lists of pieces and subscribed players, based on their frustum. Should take into account the object manager and that some pieces might not be locally available.

Dragging a piece at the edge should move the board in that direction.

Creates a protocol to allow forwarding and broadcasting of messages from appserver to appserver(s). This mechanism allows deployment of the game on-the-fly, versus having to create configuration files that are individual to each app server.

Scenario:

1. drag and drop a piece so that it intersects its correct cell, but does not magnet (ie the mouse should remain outside of the cell)
2. click on the portion of the piece that also collides with its correct cell: the piece binds/magnets locally, but not across all clients

I don't know if a drop+bind message is sent at all from the client, so the issue may be client or server side. (seems to be client, though)

The space partitioning module may require moving clients to different app servers for increased performance.

Fix it by 1) keeping it alive every x hours by running a simple operation on every cursor, or 2) increase the timeout value to infinite. Going with 1 for now..

There is no obvious way of noticing that your client has disconnected from the server, as functionality remains intact without contact from server.

I think the main bottleneck when running 20 bots on a single machine is when receiving messages. In the java code, the 20 socket threads (1 per bot) most likely blocked each other all the time, whether user or kernel threads. See http://en.wikipedia.org/wiki/Thread_%28computer_science%29#I.2FO_and_scheduling

Hence, sockets should be non-blocking. That means using epoll on their file descriptors. This is low-level stuff, so there may be a python lib or project for that. Maybe from tornado?

Similar do dragging, only allow zooming to the size of the board

Client should perform all actions optimistically and perform roll back when conflicts happen at the server.

Create the module that will do space partitioning for the jigsaw puzzle in order to improve performance.

The client and server codes so far should nearly support clients with different canvas sizes. So far, it's only been tried with 800x600.

Create events that disrupt gameplay and make the game more dynamic. Examples include "exploding" pieces in certain areas (due to a meteor or some other twisted plot design), blacking out pieces and slowly fading them back as user approaches the correct position, etc.
More ideas, insert in comments

Python may have a library to measure the upstream and downstream from/to an ip addr on each of the network interfaces of a machine.

I think this measurement tool should be standalone and remain an outside observer of the machine as a whole, and not only of the clients/proxy/server/db processes.

Draw the background puzzle image in the background as help to the user

Two refactorings are required:

1. RCAT's functionality is too mixed up in the developers application. Creating an rcat.py that will do all the tornado initialization, ip/port reading, etc etc.

2. MySQL Connector is intruding in OBM territory. OBM should be repsonsible for determining who owns the object and contacting the owner for changes and updates. MySQL Connector is responsible to find objects in database and retrieve, insert or update them. Keeping the same API, just removing "location" checks. Also removing location field from tables.
   Also, all reference to other servers will be centralized around adm ids. The OBM will have its own table where adm id gets converted to a host:ip, so that proxies don't have to be involved in this fast type of communication. But talking only in one language(adm ids) makes thing simpleer

log.debug and others are good to know what's going on in the proxy and server (and other components). But we also need to log over time how much they consume in terms of:

• CPU
• RAM
• upstream (by port, so that we can distinguish between proxy->server and proxy->client)
• downstream (by port too)

Bonus:

• how many packets TCP resends (does that account for collisions?)
• ...?

This logging may need to be done in another file (ie another logger). Checking every second may be alright (checking more often won't add any benefit).

It's annoying to unpack arguments given by the developer >_<

When dropping a piece on top of another, the piece should be on the top of the pile.

Scaling only works with a value of 2, might uncover future bugs