
<html><body><div>Hello,</div><div><br></div><div>thank you for the detailed answer!<br></div><div><br></div><div>> Regarding distance inconsistency</div><div><br></div><div>I mistakenly said that the inconsistency is between local and remote graphs, while it was in fact between regular and transitive distance algorithms regardless of remoteness. I believe this is a bug in the transitive searcher implementation for the special case when the starting and destination nodes are equal.</div><div><br></div><div>In first interation, transitive searcher only checks the neighbours of starting node for presence the destination node (and terminates if it is found), so destination node is missed if it is equal to the starting node, as it is not its own neighbour, and is only found in the second iteration. So in this case the transitive searcher returns the size of the smallest loop containing the starting/destination node, instead of zero.</div><div><br></div><div>Jakub Pelc<br></div><br><aside>---------- PÅ¯vodnÃ e-mail ----------<br>Od: Vlastimil Dort <dort@d3s.mff.cuni.cz><br>Komu: nswi080@d3s.mff.cuni.cz<br>Datum: 10. 3. 2023 7:39:08<br>PÅedmÄt: Re: [NSWI080] RMI - method calls on server-returned objects</aside><br><blockquote data-email="dort@d3s.mff.cuni.cz">Dear Jakub Pelc,<br><br>Let's start with the central question:<br><br>Yes, an object needs to be exported in order to be remotely accessible <br>(and it changes what happens if a reference to that object is passed <br>through a method invocation).<br><br>That's why our examples always include exporting the object. You can <br>easily test that implementing Remote is not enough, by taking one of our <br>examples and changing it to not export the object.<br><br>In task 1 subtask 3, the nodes should be remotely accessible objects on <br>the server, accessed from the client using RMI. You should be able to <br>piece together what is necessary in order to make this happen.<br><br>Your assumption is correct. Note that it would be quite useless if the <br>remote factory returned serialized nodes. For the client, it would be <br>just a slower way to create empty nodes, the graph would be constructed <br>on the client, and in the search phase, it would behave the same as the <br>first (fully local) variant.<br><br>Regarding distance inconsistency, first double check that both graphs <br>are really the same and that you are not mixing local and remote nodes. <br>If you still have problem after that, you can send me your code (do not <br>send it to the mailing list), so I can check.<br><br>Vlastimil Dort<br><br>Dne 08. 03. 23 v 11:57 Jakub Pelc napsal(a):<br>> Hello,<br>><br>> I have a question regarding Task 1 subtask 3 (local searcher, remote <br>> nodes): in the remote node factory, should the returned Node objects <br>> be exported? Should I simply 1) `return new NodeImpl();` or 2) export <br>> the new NodeImpl first and returned the exported object?<br>><br>> As far as I know, the first would just return the Node object <br>> serialized (I modified the Node interface to extent both Remote and <br>> Serializable), but constructing the graph edges on the client with <br>> deserialized Nodes would just create the graph locally, whereas the <br>> second option would cause the client to work with Node stubs, where <br>> method calls are passed to the server, so when client creates edges, <br>> they would correctly be created on the server-side node objects.<br>><br>> Is this assumption correct?<br>><br>> It is not entirely clear to me how the Remote interface and object <br>> exporting interact with passing/returning such objects to remote <br>> methods, eg. whether the Remote interface is enough to cause the <br>> object's methods to be run at the object's machine of origin instead <br>> of the local machine, or if the object also needs to be explicitly <br>> exported.<br>><br>> Another problem is that when using the second approach, I sometimes <br>> get inconsistent distances when measured on identical local and remote <br>> node graphs, so I guess my assumption might be wrong, but the second <br>> approach is also much slower, implying many roundtrips between client <br>> and server, which implies that my assumption is correct.<br>><br>> Thank you,<br>> Jakub Pelc<br>><br>_______________________________________________<br>NSWI080 mailing list<br>NSWI080@d3s.mff.cuni.cz<br>https://d3s.mff.cuni.cz/mailman/listinfo/nswi080<br></blockquote></body></html>