[NSWI080] RMI - method calls on server-returned objects

[Jakub Pelc]

Hello,




thank you for the detailed answer!





> Regarding distance inconsistency




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.




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.




Jakub Pelc


---------- Původní e-mail ----------
Od: Vlastimil Dort <dort at d3s.mff.cuni.cz>
Komu: nswi080 at d3s.mff.cuni.cz
Datum: 10. 3. 2023 7:39:08
Předmět: Re: [NSWI080] RMI - method calls on server-returned objects
"Dear Jakub Pelc,

Let's start with the central question:

Yes, an object needs to be exported in order to be remotely accessible 
(and it changes what happens if a reference to that object is passed 
through a method invocation).

That's why our examples always include exporting the object. You can 
easily test that implementing Remote is not enough, by taking one of our 
examples and changing it to not export the object.

In task 1 subtask 3, the nodes should be remotely accessible objects on 
the server, accessed from the client using RMI. You should be able to 
piece together what is necessary in order to make this happen.

Your assumption is correct. Note that it would be quite useless if the 
remote factory returned serialized nodes. For the client, it would be 
just a slower way to create empty nodes, the graph would be constructed 
on the client, and in the search phase, it would behave the same as the 
first (fully local) variant.

Regarding distance inconsistency, first double check that both graphs 
are really the same and that you are not mixing local and remote nodes. 
If you still have problem after that, you can send me your code (do not 
send it to the mailing list), so I can check.

Vlastimil Dort

Dne 08. 03. 23 v 11:57 Jakub Pelc napsal(a):
> Hello,
>
> I have a question regarding Task 1 subtask 3 (local searcher, remote 
> nodes): in the remote node factory, should the returned Node objects 
> be exported? Should I simply 1) `return new NodeImpl();` or 2) export 
> the new NodeImpl first and returned the exported object?
>
> As far as I know, the first would just return the Node object 
> serialized (I modified the Node interface to extent both Remote and 
> Serializable), but constructing the graph edges on the client with 
> deserialized Nodes would just create the graph locally, whereas the 
> second option would cause the client to work with Node stubs, where 
> method calls are passed to the server, so when client creates edges, 
> they would correctly be created on the server-side node objects.
>
> Is this assumption correct?
>
> It is not entirely clear to me how the Remote interface and object 
> exporting interact with passing/returning such objects to remote 
> methods, eg. whether the Remote interface is enough to cause the 
> object's methods to be run at the object's machine of origin instead 
> of the local machine, or if the object also needs to be explicitly 
> exported.
>
> Another problem is that when using the second approach, I sometimes 
> get inconsistent distances when measured on identical local and remote 
> node graphs, so I guess my assumption might be wrong, but the second 
> approach is also much slower, implying many roundtrips between client 
> and server, which implies that my assumption is correct.
>
> Thank you,
> Jakub Pelc
>
_______________________________________________
NSWI080 mailing list
NSWI080 at d3s.mff.cuni.cz
https://d3s.mff.cuni.cz/mailman/listinfo/nswi080
"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi080/attachments/20230310/1b1a4ee5/attachment.htm>