Backends clarifications

[Richard Arrano]

Hello,
I have a few questions about the new Backends feature:
It seems like a reserved backend allows us to have access to a sort of
unevictable memcache, is this correct? If I were doing something like
a game, would it be reasonable to have a single instance keep track of
a few pieces of vital information about each game? The sum of which
might be around 1MB of information at any given time.

How would I go about this anyway? Address the reserved instance and
how would I set a value in its memory?

And just to be clear, there's no free version of Backends, correct?

Thanks,
Richard

[Vanni Totaro]

Hi Richard.

Memcache by design will do eviction. You should keep your backend instance data in memory (e.g. global var). Be aware that even backend instance could be killed by the engine, so periodically store live status data in db.

Hope it helps.

Vanni

[Greg Darke (Google)]

I would suggest having a look at the example code in
http://backends-io.appspot.com/static/counter_demo.zip.

The code gives examples of how to use urlfetch to communicate between
a fronend and a backend. The backend (counter.py) also keeps the value
in memory, and writes out changes either within two seconds of
modifying the data, or when a shutdown notification occurs (which ever
happens first).

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

[Gregory D'alesandre]

Actually, there is!  You get $0.72 worth of backends free per day (this can be used in any configuration you'd like 9 hours of a B1 or 1 hour of a B8 + 1 hour of a B1, etc).

Greg

 

Thanks,
Richard

[Richard Arrano]

Ah that's great news then, I didn't realize that.

Greg: Thanks for the link, I was a bit misunderstood and didn't see it
in the App Engine Samples.

One thing that's intrigued me about the reserved backend, and it
mentions in the documentation, is to keep track of game states. I was
hoping someone could tell me if this setup would make sense: if I need
to update possibly hundreds of game states, and by update I mean
sending out actual updates via the Channel API, I thought I could do
this by two separate instances. One of which holds the data(there
isn't much data to keep track of, 128MB may be sufficient), the other
operates on a while loop that only exits when all games have completed
and runs every second or every other second using time.sleep(1000) or
2000. It sends out updates to each client in each game that requires
updates, and gets the data from the other backend instance. Then it
would sleep until the next iteration. Is this a sensible use of
backends or is this actually more suited to tasks? I was originally
using tasks that enqueue a new task each following second to
accomplish this. Which one would be better and why?

Thanks,
Richard

On May 12, 11:10 am, "Gregory D'alesandre" <gr...@google.com> wrote:

[Greg Darke (Google)]

This sounds like a excellent use of backends.

I believe that there is currently a limitation that a channel created
in a frontend (ie, your default version) is not able to be used to
send messages from a backend.

As noted in the Google IO talk, we are currently working on removing
this restriction. For the moment, you could work around this
limitation by creating the channel in the backend that you want to
send messages from, then pass it back to the frontend/user.

[Chiguireitor]

Hi Greg... i would like to know how are we supposed to open the
Channels in the current state of the server and SDK that are served
from a backend, i'm currently opening the channel from within the
backend and passing the token to my frontend but to no avail, here's a
little sample code:

*** On the frontend:

cmd = Command.login(id, password)
campaign= "campanamsl"

# Enqueue on the backend command list
task_name = "backend_%s_counter" % (campaign)

dct = cmd.to_dictionary()
idx = int(memcache.incr(task_name,
initial_value=0))

key_name = "%s_cmd_%i" % (task_name, idx)
memcache.set(key_name, dct, time=1000)

# Wait the token from the backend
channel = None
num = 0
while (channel is None) and (num < 10): # This (1)
loop will unlock when the backend replies with the usr info
channel = memcache.get(key_name+"_resp")
num += 1
if channel is None:
time.sleep(0.01)

if channel is not None:
ent = User(id)

memcache.set(id, ent)
sess['usr'] = ent
sess.save()

self.response.out.write(simplejson.dumps({"sta": ":-)", "chtok":
channel}))

*** On the backend:

cnt = int(memcache.get(self.counter_name)) # counter_name is
the same as task_name in the frontend

if cnt is not None:
while (cnt > self.cmds_count):
self.cmds_count += 1
cmd = memcache.get("%s_cmd_%i" % (self.counter_name,
self.cmds_count))

if (cmd is not None):
command= Command()
command.from_dictionary(cmd)
ent = None

if command.mapa is None:
map = self.campaign.pos['map']
else:
map = int(command.map)

ents = self.ents_per_map[map]
try:
ent = ents[command.origin]
except KeyError:
# Probably a SPAWN or LOGIN
if command.tipo == Command.SPAWN:
ent = memcache.get(command.origin)
elif command.tipo == Command.LOGIN:
# Not verifying user password yet
chan =
channel.create_channel(command.origin)
memcache.set("%s_cmd_%i_resp" %
(self.counter_name, self.cmds_count), chan, time=1000) # This unblock
the (1) loop in the frontend

***

The client side channel gets the token correctly, however nothing is
received on the onmessage event of my channel handler. After a while
the backend instance begins throwing "ProtocolBufferDecodeError:
corrupted" on line 481 on google\net\proto\ProtocolBuffer.py :-(

Please, tell me what i'm doing wrong here (if you can figure it out,
of course)

On 13 mayo, 14:16, "Greg Darke (Google)" <darke+goo...@google.com>
wrote:

> This sounds like a excellent use of backends.
>
> I believe that there is currently a limitation that a channel created
> in a frontend (ie, your default version) is not able to be used to
> send messages from a backend.
>
> As noted in the Google IO talk, we are currently working on removing
> this restriction. For the moment, you could work around this
> limitation by creating the channel in the backend that you want to
> send messages from, then pass it back to the frontend/user.
>

[Greg Darke (Google)]

Sorry about the delay. I did not notice the reply to this thread.

I will have a look into this next week.