I'm working on taxi booking service and using Parse as a backend.
-Client adding new Order (which contains pick up point coordinates and destination point coordinates), and cloud code should match the closest Driver (parameter 'currentLocation') to the pick point.
-Then system offering an Order to the Driver, if Driver not responding or declining an Order, system should find another Driver.
What algorithm should I have on cloud code side? I think I should have anything like matching session, but have no idea of doing this yet. Also: driver should accept order in 2mins, or order will be declined and will go to another Driver. Thank you!
Related
I am building an application that uses the native neo4j JavaScript driver. I want to make sure that my code will work if we migrate to a causal cluster.
The online documentation doesn't seem to be clear about how to do this: I notice sparse references to things like "bookmarks" and "reading what you have written", etc. But how it all fits together is unclear.
Can someone please provide a synopsis?
To use causal cluster you will need to change :
1) the url connection : replace bolt://localhost:7687 by bolt+routing://localhost:7687
This will allow your application to make some LB query to the cluster, and be fault tolerant without doing anything else
2) When you open a new session, you should specified what you will do into this session, ie. READ or WRITE.
This will help the driver to choose the good server (ie a core or a replica server). Otherwise it assumes you will do some WRITE operations, and the driver will always choose a core server ...
3) because you will be on a cluster env., there is some lag (some secondes) for the propagation of an update inside the cluster.
Or sometimes, you need to read your own writes within two sessions. It's where you will need the bookmark functionality.
Documentation is here : https://neo4j.com/docs/developer-manual/current/drivers/
Cheers.
I'm trying to understanding how a broadcastHashJoin is executed.
I know that the little table is send broadcast to all node, but next the result is sent back to the driver?
I'm using the spark ui to undestand how network traffic is managed but i don't get relevant result and the driver result always empty:
Why i can't see traffic to driver?
Relation which is to be broadcasted is collected to the driver
Collected relation is hashed locally
Hashed relation is used to create a broadcast variable
Broadcasted relation is used to compute join in parallel
Missing data from the driver you see most likely correspond to hashing part which is not executed inside job and doesn't create useful metrics.
I want to be able to show (by device) open/blocked status for a given protocol between two devices/ports on a network. In other words, I need to output a list of network devices (firewalls & switches) between Server A and Server B and indicate whether the request should (according to each device's rules) be allowed through or blocked.
I'm starting with the Cisco networking devices, which are centrally managed by Cisco's Security Manager (CSM) application (version 4.2). I'm new to network management automation programming and want to make sure I'm not overlooking an obvious best way to handle this.
So far it's looking like I'll need to periodically export and ETL device rules out of CSM (they have a perl script that I can call to do this I believe) and into a separate database, then write some custom SQL code to determine which devices on a route between two hosts/ports will allow or block traffic of the given protocol?
Am I on the right track, or is there a better way to go about this?
If I understood your question, I think you can run a TCL script inside the Cisco equipments do collect the necessary information and transfer it to a central server, form there import it to a database and then correlate that information.
Hope that helps you in your work.
I've read in Wikipedia that one of the ways to obtain geolocation information for a given IP is done using DNSBL. The following link is: http://en.wikipedia.org/wiki/Geolocation_software#Data_sources
Could someone explain me how this is done? And in general, what is DNSBL rather than a banning list?
DNSBL is a blacklist/database based on dns. DNS is just your api to get a specific result. Others could be HTTP or a simple local file.
IP needs routing and thus the physical machines doing that are placed in certain locations. Knowing that makes it possible to collect data where the routing points are and thus get to closest location of a certain IP address. (Knowing that there are 5 big co
http://en.wikipedia.org/wiki/Geo_targeting
http://en.wikipedia.org/wiki/LOC_record
http://en.wikipedia.org/wiki/Regional_Internet_registry
I'm setting up a iPhone tracking system for my friends, so they can submit their location to my website by their iPhone, anywhere, anytime - by WiFi or cellular data.
The website will use Google Maps for their coordination's so that my other friends can track where they are, however, it is the accuracy of the IP to coordinates to Google Maps is what I'm concerned about, exactly how accurate is it to use Google Maps that would track down the locations by an IP address?
I was thinking about 95%, but this was tested in a village which was quite fairly accurate, but what happens if it was in a city? Would this cause unaccurate locations?
Any kind help appreciated.
IP geolocation is really hit-or-miss, depending on both how the user's ISP assigns IPs and on the IP geolocation database you're using. For instance, I made a simple PHP script, IP2FireEagle, which looks up your IP. I found that the database kept placing me 10+ km to the west of where I really was. Updating my entry in Host IP wasn't the greatest, as it soon got reverted, presumably by someone also occasionally assigned that IP by my ISP! That being said, I found that Clarke has very accurate coordinates (not that this it's using IP geolocation per se but rather Skyhook's API and their WiFi geolocation database).
If it's a website for your friends and you know they have iPhones, I would suggest using its browser's support for navigator.geolocation.getCurrentPosition(). That is, get the location via Javascript and submit it to your server via an AJAX call. Even better since you want to use Google Maps, they give you a short tutorial on how get your friends' locations and then update a map.
Excerpt From:
http://www.clickz.com/822881
IP targeting has been around since the early days of ad serving. It's not very hard to write code that will strip the IP address from a request, compare it to a database, and deliver an ad accordingly. The true difficulty, as we shall see, is building and maintaining an IP database.
One of the first applications of information in an IP database was targeting to specific geographic regions. Most commercial ad management systems have IP databases that can make geographic targeting possible. However, there are a couple weaknesses in this method. The first (and biggest) problem is that, for various reasons, not all IPs can be mapped to an accurate location.
Take all the IPs associated with AOL users, for instance. Anybody who has seen a WebTrends report knows that all AOL users appear to be coming from somewhere in Virginia. This is caused by AOL's use of proxy servers to handle their web requests.
In the interest of saving space, we won't get into the reasons why AOL makes use of proxy servers. The important thing is that AOL does use them, and as a result, all its users appear to be accessing the web from Virginia. Thus, it is impossible to attach meaningful geographic location data to an AOL IP, and those IPs must be discarded from any database that wants to maintain a reasonable degree of accuracy.
Other ISPs and networks may use a method known as dynamic IP allocation for its users. In other words, a user might have a different IP address every time he visits the Internet. You can see how this might affect the accuracy of a database.
But the real difficulty in discerning geography from an IP address has to do with the level of specificity that a media planner might expect from this targeting method. The first few geo-targeted campaigns that I put together early in my career had to be accurate to the ZIP code level. This level of specificity is not practical via IP targeting.