Just transform your graph to something that can be searched easily!
How?
Given a a graph X {A, E}
(A being the set of vertices, E
being the set of (directed) edges), construct a graph X' {A, E*}
, such that an edge is in E*
(from point B to point D) iff there is a pair of edges in E such that the first is from B to C, and the second - from C to D.
You may also want to keep a reverse mapping for edges (I.e. how was the edge constructed?)
How difficult is this?
Potentially up to N^3 where N is the number of vertexes, depending on your graph structure. Given that path search algorithms are usually in the order of N^2 to N^3, that should be fine. Also N^3 is the naive way - you may be able to find a better way.
What do I do with it?
Given this new graph - Any even-length path in X
is a path in X'
if you throw out every odd vertex. Also - any path through X'
is an even-length path through X
if you fill in the gaps via the reverse mapping from the first section. I.E. You have a surjection from even-length paths in X
to paths in X'
.
This surjection also preserves path length comparison - a path K' is longer that a path L' in X'
iff their corresponding paths in X
- K and L - have the same relationship, i.e. K is longer than L.
Eh... OK, so what?
Well all this theory lets you claim one neat thing - the shortest path through X'
is going to have a corresponding shortest even-length path through X
. This graph is going to have the same number of vertexes, and maybe a larger or smaller number of edges. Hence any of the numerous path-finding algorithms will work - your question implies you can use those already.
Can I do all this without the extra graph?
Why yes! Of course you can! Just use your imagination! As in - don't explicitly construct the extra graph. Just imply it. This will require changes to the actual path searching algorithm - when asked about nodes adjacent to some given node, instead of listing everything connected directly - list everything connected through exactly 2 edges.
Depending on your situation this may or may not be a better solution. The "theoretical" one allows usage of search algorithms out-of-the-box, but suffers from a lot of setup. The second one mitigates setup at the cost of modifying the algorithms (and IMHO has more room for mistakes)