{ "info": { "author": "Da_Blitz", "author_email": "epiccode@epic-man.net", "bugtrack_url": null, "classifiers": [], "description": "Epic Server\n===========\n\nEpic Server is a runtime/harness for running code that offers multi-process and \nmulti-machine execution. It handles aspects such as auto-discovery and \nmessaging and abstracts these in an easy to use for to allow you to focus on \nwriting the code to run your services.\n\nNote: This is alpha software. The below talks about features coming in the 0.1 \nrelease, the project is in a runnable state at the moment but does not include \nthe multi machine/process execution at this time, this is expected to be \nfinished shortly before official release\n\nExample\n-------\n\n.. code-block::\n\n from epicserver.objects import Entity\n\n class GameEntity(Entity): pass\n\n class Player(GameEntity):\n score = 0\n async enter_level(self, barrels):\n for barrel in barrels:\n # shoot the barrel\n killed = await barrel.on_hit()\n if killed\n self.score += 1\n\n async get_score(self):\n return self.score\n\n class Barrel(GameEntity):\n team = \"Society for the prevention of cruelty to barrels'\n async on_hit(self):\n print(\"What, did you expect me to explode?\")\n return False\n\n async def setup(pool)\n pool.bind(GameEntity)\n barrels = [pool.Barrel[i] for i in range(30)]\n player = pool.Player['Bob: Slayer of armoured cylinders']\n\n await player.enter_level(barrels)\n score = await player.get_score()\n\n print(f\"New High scrore for player: {score}\")\n\n\n\nFeatures\n--------\n\n\n* Based on raw async/await\n* Inter object based messaging that looks like normal async method calls\n* Automatic 'fabric' creation, stiching togther multiple processes on the same \n or seperate machines.\n* Automatic discovery of machines\n* Virtual actors/objects, no explicit instantiation required\n* Isolated and pluggable systems allow swapping in diffrent implementations\n (eg Serialisation, networking)\n* Automatic object percistance to disk (aka 'saving')\n* Garbage colleciton of objects\n* Python >= 3.6 only support\n\nUse Cases\n---------\n\n\n* Distributed Game Backend\n* Agent Simulation\n* Communciation {latform (instant messaging, twiiter like systems)\n* Graph based processing\n\nEpic Server is ideal for anything that is messaging heavy and designed around \nobjects that need to communicate\n\nEpix Server is not a 'drop in' solution to python to gain concurrency. \nApplications seeking to exploit the parallelism of Epic Server will need to be \nwritten to use it. Code that uses fork or threads can be adapted to work (by \nmaking each fork/thread a separate object) however Epic Server is focused on \nhigh levels of parallelism (executing contexts is 10s to 100s of times the number \nof CPU's) and short lived 'calculations'\n\nInspriaration\n-------------\n\nEpicserver draws fromconcepts from many diffrent languages and libraries, a \nshort list is included below\n\n\n* Orleans from microsoft research (dotnet/C#). Used as the machinary behind \n Halo 5 and other games\n* Erlang\n* Stackless Python\n* AsyncIO\n* SansIO\n* Zope/ZODB\n\nWhile the concepts of many of the above can be ported straight to python, \nmodification of the concepts to make them feel fammilar to python programmers \nwhere undertaken in an attempt to make the resulting framework more pythonic \nand fit better with existing python ecosystems.\n\nImplimentation\n--------------\n\nEpic Server consists of an event loop running in the main thread that is \nresponsible for the execution of work, as well as several background IO threads \nresponsible for sending and reciving IO requests as well as handling IO (both \ndisk and network). Additional threads can be utilized for other blocking calls \nthat may arrise such as Database access.\n\nAll access to thes IO threads is dont via message passing and mediated by the \nevent loop\n\nIO Loop\n=======\n\nEpic Server is implemented as an IO Loop with a number of 'syscalls' that \ncorrespond to high level concepts. Rather than focusing on how to perform the \nIO, Epic Server presents primitives such as 'persist to database' or 'Call \nremote object' leaving the implementation up to the server and allowing you to \navoid having IO routines embedded in your business logic that would need to be \nmocked out for testing.\n\nBy moving the IO out of the program and replacing it with a token based syscall \nsystem, one can simply and quickly test buisness logic without havign to mock \nout te IO routines or simulate services. Testing becomes a simple process of \nsending the code messages and checing the repsponses.\n\nMoving the IO out of the code also allows high performance implemetnations such \nas TIPC or ininiband to be plugged in without modifcation of code, this applies \nto which database is in use or the searlisation library allowing futher updates \nto features and performance without having to rework (or test) code.\n\nConcurrency\n===========\n\nA number of the implementations this project was inspired by have very explict \nideas in regards to the concurrency model and interleaving of requests, a short \nsummary is below:\n\n\n* Orleans: Objects are single threaded, only one request may be performed on \n an object at a time\n* Erlang: Actors are lite-weight processes that communicate via mailboxes\n* Stackless Python: Follows CPython/GIL Semantics\n* AsyncIO: Cooperative multitasking, yields control flow at yield/await \n statements, Guaranteed exclusive execution between these two points (Providing \n threading is not used)\n\nEpic Server is composed of multiple Python processes that may be running on the \nsame or different machines. Each Python process has one 'execution' thread that \ncorresponds to the main thread as well as a number of background threads for IO \n(DB access, sending requests and receiving requests)..\n\nFrom the point of view of user code, a method call has exclusive access tot he \nCPU between 'yield points' (yield/await). At these points, the running context \nmay be changed and other code may be executed. This is identical to AsyncIOs \nguarantees and a lot less restrictive (and dangerous) than other frameworks \nsuch as Orleans while being more in line with what python programmers expect.\n\nIn contrast to the Orleans approach the above means that multiple instances of \nthe same method call can be executing and will be interleaved. Should method \nlevel or object level locking be required to introduce Orleans like semantics \nbe required then a decorator will need to be used to ensure this.\n\nThe Use of IO threads should not interfere with the execution thread as these \nare interacted with via message passing and mediated by the event loop. \nMutation of the messages after being 'handed off' however may cause \nundesirable effects and as such all 'sent' messages should not be further \nmodified and references to them dropped.\n\nAs an object can only be running in a single process at a time, Parallelism can \nbe achieved by executing multiple different objects in multiple processes at \nonce. Spreading the work over multiple objects can be used to achieve speedups\n\nFile IO\n=======\n\nFile IO looks simmilar to normal file IO via open(). Under the hood however the \nimplemented in a 'completion ports' fashion, rather than notifing when a socket \nor file is ready, a write or read is performed and the calling process is \nnotified upon compleation of the entire event or an erorr is returned. This \nlower level interface is exposed to user code should the high level be \ninsufficent.\n\nBy abstracting the IO model epicserver hopes to achive independence froma ny \none IO loop allowing them to be plugged in with minimal effort.", "description_content_type": null, "docs_url": null, "download_url": "", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "http://blitz.works/epic/epic-server", "keywords": "game mmo rpg asyncio", "license": "MIT BSD", "maintainer": "", "maintainer_email": "", "name": "epicserver", "package_url": "https://pypi.org/project/epicserver/", "platform": "", "project_url": "https://pypi.org/project/epicserver/", "project_urls": { "Homepage": "http://blitz.works/epic/epic-server" }, "release_url": "https://pypi.org/project/epicserver/0.1.1/", "requires_dist": null, "requires_python": "", "summary": "Online Persistent game infrastructure", "version": "0.1.1" }, "last_serial": 2954358, "releases": { "0.1": [ { "comment_text": "", "digests": { "md5": "d62afe588be661574aa1741912fba541", "sha256": "3d33c8f4049b0c813d04eeaf2749acfc37bf84f37bb6eded65cbafe3f3b4cb82" }, "downloads": -1, "filename": "epicserver-0.1.tar.gz", "has_sig": false, "md5_digest": "d62afe588be661574aa1741912fba541", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 10341, "upload_time": "2017-06-11T13:36:10", "url": "https://files.pythonhosted.org/packages/34/bc/a2025e2f05326c24e5ea2908be7575d32e81736b283cd6303764cdcb40ef/epicserver-0.1.tar.gz" } ], "0.1.1": [ { "comment_text": "", "digests": { "md5": "32fdd522eda3780446c404350c03041f", "sha256": "e6c3126c0709afda71db07ed04a82fab63ac8bbd277fbb77e5e3e6041ee83730" }, "downloads": -1, "filename": "epicserver-0.1.1.zip", "has_sig": false, "md5_digest": "32fdd522eda3780446c404350c03041f", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 20500, "upload_time": "2017-06-16T12:03:56", "url": "https://files.pythonhosted.org/packages/a4/ed/d000c2602c023324d1a0b5c1aac250df0f96fc64bbb0ec88a2c11dea4678/epicserver-0.1.1.zip" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "32fdd522eda3780446c404350c03041f", "sha256": "e6c3126c0709afda71db07ed04a82fab63ac8bbd277fbb77e5e3e6041ee83730" }, "downloads": -1, "filename": "epicserver-0.1.1.zip", "has_sig": false, "md5_digest": "32fdd522eda3780446c404350c03041f", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 20500, "upload_time": "2017-06-16T12:03:56", "url": "https://files.pythonhosted.org/packages/a4/ed/d000c2602c023324d1a0b5c1aac250df0f96fc64bbb0ec88a2c11dea4678/epicserver-0.1.1.zip" } ] }