troydavisson / PHRETS

PHP client library for interacting with a RETS server to pull real estate listings, photos and other data made available from an MLS system
http://troda.com
MIT License
451 stars 234 forks source link

Reuse Sessions? #186

Open kodie opened 6 years ago

kodie commented 6 years ago

I have built a script that allows me to dynamically display images from a RETS server. So basically something like this:

http://mywebsite.com/img.php?resource=Property&type=Photo&id=123456&index=1

and then I can do stuff like this: <img src="http://mywebsite.com/img.php?resource=Property&type=Photo&id=123456&index=1">

and it works beautifully. However, if I have like 10 images on a page, some of the images will randomly not show. I'm assuming this is due to logging into the server as the same user 10 separate times at the same time.

Is there a way I can get session details to store and reuse?

bradroberts commented 6 years ago

We do something similar. I haven't run into this issue yet, but I have thought about the possibility of simultaneous sessions being a problem. Here's two things we currently do that might help you cut down on the number of RETS logins and take some work off both your server and the RETS server.

Caching Locally. Your img.php script could store the photo on the filesystem, and before fetching the photo from RETS, check to see if you already have it. You should include the PhotoTimestamp in the URL as well so that your cache is updated when photos are modified. The workflow might look like this.

  1. Create a unique file name based on resource (property) ID, photo index, and photo timestamp.
  2. Check to see if a photo with this file name exists on the local filesystem, and if so, return it.
  3. If the photo doesn't exist locally, fetch it from RETS and store it using the unique file name before returning it.

You might also need to run a cleanup process to remove old files. Possibly by running a scheduled task that removes photos of inactive listings.

Using a Content Delivery Network. We use AWS CloudFront, but there are lots of great services out there. Here's how that works.

  1. You replace your photo URLs with CDN equivalents like https://yoursite.cloudfront.com/img.php?resource=Property&type=Photo&id=123456&index=1&Timestamp=1510801270
  2. The first time someone requests an image, CloudFront fetches the photo from your server using your source URL (the one you're currently using). The photo is then cached on the CDN and subsequent requests never hit your server.

These two methods could be used exclusively or together. I know this doesn't answer your question specifically, but hopefully it might be helpful.

StaleSpace commented 5 years ago

@kodie Did you find any solution?

kodie commented 5 years ago

@php5-webmob As @bradroberts suggested, we are caching the results locally. So basically our app is getting images in a two-step process. First, make a RETS call to download all the images we need and save them in local cache, then whenever we need to server an image we just load them from that cache. It's been working pretty good for us so far, however we still run into "Too Many Login" errors from time to time.

maietta commented 1 year ago

Yesterday, I reached a hard limit that resulted in an outage and a day's worth of lost work.

I have encountered a problem where it is not possible to store the $rets connection in a session cookie due to it being a Closure with runtime information. To overcome this, a custom-built session handler needs to be implemented. From examining the source code, it appears that the existing "session/cookies" are only for multiple requests made using the offset and limit strategy. I had previously assumed that the "session/cookies" feature of PHPRETS included the ability to cache sessions, thereby preventing me from reaching the hard limit on logins per day with my RETS feed provider for several years.

This is a fundamentally flawed system and am thinking a whole new RETS library is needed. Something that can be coded to persist a session to avoid hard login limits per day.