yes:
def connect(address):
socket.settimeout(10)
s = socket.socket()
return s.connect(address)
mysocket = cache.ram('socket',lambda address=(ip,port):
connect(address),3600)
mysocket.send('hello world')
But mind that s.connect may block.
On Wednesday, 6 February 2013 19:32:49 UTC-6, Bernard wrote:
>
> Is it possible to use cache.ram for a TCP socket?
> In my setup, establishing a TCP connection to a remote machine is time
> consuming and I need to find a workaround to have snappier response to the
> Web UI.
>
> Any help appreciated.
>
> Thanks,
> Bernard
>
> On Monday, February 4, 2013 11:46:22 AM UTC-8, Bernard wrote:
>>
>> Hi web2py users,
>> I've been using web2py for a few months now, thank you to the
>> developers for the great work.
>>
>> I'm working on an interactive web based monitoring and control
>> Application that communicates with ~30 mobile field units at a time to get
>> periodic 'semi-realtime' status reports (2-5 second poll period) and allow
>> the user to change settings of the field units on demand. The
>> communications channel is using TCP sockets: the web2py workstation end is
>> the TCP client and each field unit is running as a TCP server on an
>> embedded low performance field unit. The front end is currently doing
>> periodic Ajax polling every 2 seconds and updating the GUI. I also
>> would like to support multiple web users connected to the Application on
>> the front end.
>>
>> I've searched the mailing lists of web2py and other frameworks but
>> could not find a use case similar to mine. There are many ways
>> implementing this, it's not easy to figure out which is best and what
>> pitfalls may lie ahead.
>> Here are some of the approaches that I have considered:
>> 1- Use a background asynchronous "Data Acquisition" task always running
>> and fills a "RealTime" table in the database (by polling all field units
>> every 2 seconds). For each web request, the controller would then pick up
>> the latest values from the database and serve them up to Web clients
>> without having to worry about pulling the data. The background task keeps
>> the sockets open to improve performance.
>> 2- The controller communicates with the ~30 field units directly,
>> bypassing any database overhead. The controller needs a persistent
>> reference to the 30 TCP sockets to make the comms faster. Is there a way to
>> parallelize the TCP request/response in the request thread to
>> communicate with ~30 units quickly? To handle multiple Web users, I can
>> cache the controller function so that it doesn't run on every web client
>> request.
>> 3- Have web2py controller communicate with a separate data acquisition
>> process
>> via message queues. The web2py parts would never deal with the low level
>> comms and the external data acquisition component would abstract all
>> that. However, this is at the expense of having to create an external
>> component and define the interface to it and adding a messaging framework
>> between web2py and the data acquisition process.
>> 4- Controller kicks off a worker thread that collects the field unit
>> status. Controller function cached to avoid having a task for every web
>> request.
>> 5- Other ideas that might be better suited to this application?
>>
>> If anybody has gone through something similar, can you please help with
>> your experience?
>> If you see any issues or potential weaknesses in any of these approaches,
>> your feedback would be greatly appreciated.
>>
>> Regards,
>> Bernard
>>
>>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
