-- Scott On 04/01/2016 12:08 PM, Bartos, Christopher wrote:
I opened up 2642 and it seems to be the same speed as before.On Mar 30, 2016, at 1:53 PM, Bartos, Christopher <bartos.25@osu.edu> wrote: Hello, My plan is to open udp and tcp on port 2642. Thanks for all your help. Sorry, Jane, for not seeing your email last week. Thanks everyone! Forgive the typo... your 1811.1 prefix advertises service on UDP 2642 (not 2641). RobertOn 2016-03-30, at 13:36, Robert Tupelo-Schneck <schneck@cnri.reston.va.us> wrote: Chris, your 1811 server is open to public resolution at UDP 2641, TCP 2641, and HTTP 8000. Your 1811.1 server is only open on HTTP 8002, but your prefix does advertise service on UDP 2641 and TCP 2642. As Scott suggested, this is why resolution is slow. Best is to open UDP 2642 and TCP 2642 at your firewall. If strictly necessary, CNRI can change your prefix information to advertise only TCP 8002. On a separate note, the resolution behavior at 1811.1 is unusual. So 1811.1/1112 resolves to the same value at 1811/1112. I'm curious to hear more about the value of that to you. Do you want 1811/1112 to be the public handle of record, as it were, or 1811.1/1112? Also, you should check your spam filter, as Jane Euler at CNRI emailed you about the matter of the ports being closed last week. Best, RobertOn 2016-03-30, at 12:46, Scott Prater <scott.prater@wisc.edu> wrote: Yes, that would most definitely be a cause for a delay. Can you temporarily open the handle server TCP and UDP ports to the world, as see if the resolution is faster? -- Scott On 03/30/2016 11:40 AM, Bartos, Christopher wrote:The only ones we have open to the world is our HTTP protocols opened on 8002 where the handle server is running on. We have 2 handle servers 1) DSpace instance and 2) Regular Handle Server They are running on HTTP 8000 and HTTP 8002 respectively. Neither of the UDP / TCP ports are open to the world. Would that be cause of slowness? Thanks, ChrisOn Mar 30, 2016, at 12:24 PM, Scott Prater <scott.prater@wisc.edu <mailto:scott.prater@wisc.edu>> wrote: What ports do you have open to the world on your handle server, to which protocols? In my experience, slowness in resolution is usually because the udp handle port is closed to the world, causing the client to fall back to tcp, and maybe even http, to resolve. Looking at the output of the handle client as it attempts to resolve will give you a hint as to where the delay is. -- Scott On 03/30/2016 10:46 AM, Bartos, Christopher wrote:Hi, I've overridden the HandleStorage class in Handle Server so that it will attempt to resolve a specific prefix internally, and if it doesn’t resolve, it will attempt to resolve itself, meaning, it runs the normal BDJBEHandleStorage class to resolve it’s own handle. Here is my new class: https://github.com/lupulin/MultiServerHandleStorage/blob/master/MultiServerHandleStorage.java My question: it’s pretty quick locally. You can check it: http://140.254.87.133:8002/1811.1/OSU123 will resolve itself. http://140.254.87.133:8002/1811.1/1112 will resolve a different handle server. However, going through hdl.handle.net <http://hdl.handle.net>: http://hdl.handle.net/1811.1/OSU123andhttp://hdl.handle.net/1811.1/1112 Is very, very slow. My question, is that I’m wondering if there is a way that we can speed up the HandleStorage implementation on our side or if there is nothing we can do. Also, if there is a better way to do what we are attempting. Our goal is to have 2 handle servers, both with the same prefix, but the one that is publicly available will use our custom HandleStorage class. Thanks in advance, Chris _______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us <mailto:Handle-Info@cnri.reston.va.us> http://www.handle.net/mailman/listinfo/handle-info-- Scott Prater Shared Development Group General Library System University of Wisconsin - Madison-- Scott Prater Shared Development Group General Library System University of Wisconsin - Madison _______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info
-- Scott Prater Shared Development Group General Library System University of Wisconsin - Madison
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info