UDP is now open and it still takes ~4 seconds to resolve. > On Apr 1, 2016, at 1:27 PM, Robert Tupelo-Schneck <schneck@cnri.reston.va.us> wrote: > > You need to open both UDP 2642 and TCP 2642. Currently TCP 2642 is open, but not UDP 2642. > > Robert > >> On 2016-04-01, at 13:08, Bartos, Christopher <bartos.25@osu.edu> 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). >>> >>> Robert >>> >>>> On 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, >>>> Robert >>>> >>>>> On 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, >>>>>> >>>>>> Chris >>>>>> >>>>>>> On 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 >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info