Good point. yes you should close it but how and why depends on your
protocol and how you use the function.
On Wednesday, 6 February 2013 20:19:31 UTC-6, Bernard wrote:
>
> Thanks, it works.
> Do I have to worry about s.close()?
>
> On Wednesday, February 6, 2013 6:12:06 PM UTC-8, Massimo Di Pierro wrote:
>>
>> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
