Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread Johan Kjölhede 
Thanks for clarifying that. We suspected that but weren't sure. We can close 
this thread ;). Thanks everyone for great input

Skickat från min iPhone

> 10 nov. 2016 kl. 18:03 skrev Patrik Nordwall :
> 
> And for the record, it's just accidental that it works with tcp. We don't 
> guarantee that the same connection is reused.
>> tors 10 nov. 2016 kl. 17:14 skrev Endre Varga :
>> Actor remote messaging is a P2P protocol and as such any kind of 
>> name-remapping is harmful. Trying to load balance Akka Remote connections I 
>> think is a mistake and makes not much sense. You *can* load balance Akka 
>> provided services of course, but you need to expose them as a different 
>> protocol (i.e. REST API, custom TCP endpoint, etc.). 
>> 
>> On Thu, Nov 10, 2016 at 5:12 PM,  
>> wrote:
>> Ok. Just wanted that confirmed. We already have a workaround for it so I was 
>> mostly just curious to see if it was needed :).
>> 
>> / Johan
>> 
>> 
>> 
>> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>> the host needs to be a stable identifier.
>> 
>> What problem are you trying to solve with the rr dns?
>> 
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>> Case:
>> 
>> I have two services (A and B) that wish to talk to each other using 
>> akka-remoting over artery.
>> Each service executes on it's own machine behind a load balancer mapping a 
>> dns name, e.g. $A resolving -> multiple IP addresses.
>> 
>> For A to talk to B, we can for example execute:
>> 
>> // Make request from an A to a B
>> val b = 
>> context.actorSelection(s"akka://$systemName@$B:$port/user/$actorName")
>> b ! Request()
>> 
>> where $B is the load balanced address that is resolved to a B instance 
>> (maybe B1, maybe B2.. etc)
>> 
>> In order for B to receive this message, B would need to have an akka conf 
>> with canonical.hostname = $B. Otherwise artery will filter out these 
>> messages...
>> 
>> So far, this works. However, now let's say this is bidirectional 
>> communication. 
>> B wants to reply to A's requests, but also, B wants to send its own 
>> independent requests to A and expect A to reply back to B.
>> 
>> B would then have something like the following code
>> // Reply from B back to A
>> def receive {
>>   case  Request() => sender() ! Reply()
>> }
>> 
>> But because A has canonical.hostname set to $A, which is a load balanced 
>> address, the reply could end up at A1, A2 or any Ai for that matter.
>> 
>> To work around this, all I can think of is to let each actor resolution 
>> actually do a manual dns lookup before calling context.actorSelection.. and 
>> write the explicit resolved address of each actor to their own akka conf.
>> Is this conclusion correct?
>> 
>> I suspect akka.tcp does not have this problem as sender() would just re-use 
>> the existing tcp connection, but artery being build on udp, will suffer from 
>> the problem above.
>> Am I missing something? :)
>> 
>> / Johan
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> -- 
>> Cheers,
>> √
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread Viktor Klang 
Consider that confirmed then. ;)

On Thu, Nov 10, 2016 at 5:12 PM, 
wrote:

> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>>
>> the host needs to be a stable identifier.
>>
>> What problem are you trying to solve with the rr dns?
>>
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>>
>>> Case:
>>>
>>> I have two services (A and B) that wish to talk to each other using
>>> akka-remoting over artery.
>>> Each service executes on it's own machine behind a load balancer mapping
>>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>>
>>> For A to talk to B, we can for example execute:
>>>
>>> // Make request from an A to a B
>>> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$a
>>> ctorName")
>>> b ! Request()
>>>
>>> where $B is the load balanced address that is resolved to a B instance
>>> (maybe B1, maybe B2.. etc)
>>>
>>> In order for B to receive this message, B would need to have an akka
>>> conf with canonical.hostname = $B. Otherwise artery will filter out these
>>> messages...
>>>
>>> So far, this works. However, now let's say this is bidirectional
>>> communication.
>>> B wants to reply to A's requests, but also, B wants to send its own
>>> independent requests to A and expect A to reply back to B.
>>>
>>> B would then have something like the following code
>>> // Reply from B back to A
>>> def receive {
>>>   case  Request() => sender() ! Reply()
>>> }
>>>
>>> But because A has canonical.hostname set to $A, which is a load balanced
>>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>>
>>> To work around this, all I can think of is to let each actor resolution
>>> actually do a manual dns lookup before calling context.actorSelection.. and
>>> write the explicit resolved address of each actor to their own akka conf.
>>> *Is this conclusion correct?*
>>>
>>> I suspect akka.tcp does not have this problem as sender() would just
>>> re-use the existing tcp connection, but artery being build on udp, will
>>> suffer from the problem above.
>>> Am I missing something? :)
>>>
>>> / Johan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread Patrik Nordwall 
And for the record, it's just accidental that it works with tcp. We don't
guarantee that the same connection is reused.
tors 10 nov. 2016 kl. 17:14 skrev Endre Varga :

> Actor remote messaging is a P2P protocol and as such any kind of
> name-remapping is harmful. Trying to load balance Akka Remote connections I
> think is a mistake and makes not much sense. You *can* load balance Akka
> provided services of course, but you need to expose them as a different
> protocol (i.e. REST API, custom TCP endpoint, etc.).
>
> On Thu, Nov 10, 2016 at 5:12 PM, 
> wrote:
>
> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>
> the host needs to be a stable identifier.
>
> What problem are you trying to solve with the rr dns?
>
> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>
> Case:
>
> I have two services (A and B) that wish to talk to each other using
> akka-remoting over artery.
> Each service executes on it's own machine behind a load balancer mapping a
> dns name, e.g. $A resolving -> multiple IP addresses.
>
> For A to talk to B, we can for example execute:
>
> // Make request from an A to a B
> val b = context.actorSelection(s"akka://$systemName@
> $B:$port/user/$actorName")
> b ! Request()
>
> where $B is the load balanced address that is resolved to a B instance
> (maybe B1, maybe B2.. etc)
>
> In order for B to receive this message, B would need to have an akka conf
> with canonical.hostname = $B. Otherwise artery will filter out these
> messages...
>
> So far, this works. However, now let's say this is bidirectional
> communication.
> B wants to reply to A's requests, but also, B wants to send its own
> independent requests to A and expect A to reply back to B.
>
> B would then have something like the following code
> // Reply from B back to A
> def receive {
>   case  Request() => sender() ! Reply()
> }
>
> But because A has canonical.hostname set to $A, which is a load balanced
> address, the reply could end up at A1, A2 or any Ai for that matter.
>
> To work around this, all I can think of is to let each actor resolution
> actually do a manual dns lookup before calling context.actorSelection.. and
> write the explicit resolved address of each actor to their own akka conf.
> *Is this conclusion correct?*
>
> I suspect akka.tcp does not have this problem as sender() would just
> re-use the existing tcp connection, but artery being build on udp, will
> suffer from the problem above.
> Am I missing something? :)
>
> / Johan
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Cheers,
> √
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread Endre Varga 
Actor remote messaging is a P2P protocol and as such any kind of
name-remapping is harmful. Trying to load balance Akka Remote connections I
think is a mistake and makes not much sense. You *can* load balance Akka
provided services of course, but you need to expose them as a different
protocol (i.e. REST API, custom TCP endpoint, etc.).

On Thu, Nov 10, 2016 at 5:12 PM, 
wrote:

> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>>
>> the host needs to be a stable identifier.
>>
>> What problem are you trying to solve with the rr dns?
>>
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>>
>>> Case:
>>>
>>> I have two services (A and B) that wish to talk to each other using
>>> akka-remoting over artery.
>>> Each service executes on it's own machine behind a load balancer mapping
>>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>>
>>> For A to talk to B, we can for example execute:
>>>
>>> // Make request from an A to a B
>>> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$a
>>> ctorName")
>>> b ! Request()
>>>
>>> where $B is the load balanced address that is resolved to a B instance
>>> (maybe B1, maybe B2.. etc)
>>>
>>> In order for B to receive this message, B would need to have an akka
>>> conf with canonical.hostname = $B. Otherwise artery will filter out these
>>> messages...
>>>
>>> So far, this works. However, now let's say this is bidirectional
>>> communication.
>>> B wants to reply to A's requests, but also, B wants to send its own
>>> independent requests to A and expect A to reply back to B.
>>>
>>> B would then have something like the following code
>>> // Reply from B back to A
>>> def receive {
>>>   case  Request() => sender() ! Reply()
>>> }
>>>
>>> But because A has canonical.hostname set to $A, which is a load balanced
>>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>>
>>> To work around this, all I can think of is to let each actor resolution
>>> actually do a manual dns lookup before calling context.actorSelection.. and
>>> write the explicit resolved address of each actor to their own akka conf.
>>> *Is this conclusion correct?*
>>>
>>> I suspect akka.tcp does not have this problem as sender() would just
>>> re-use the existing tcp connection, but artery being build on udp, will
>>> suffer from the problem above.
>>> Am I missing something? :)
>>>
>>> / Johan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread johan . kjolhede . bonniernews 
Ok. Just wanted that confirmed. We already have a workaround for it so I 
was mostly just curious to see if it was needed :).

/ Johan



Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>
> the host needs to be a stable identifier.
>
> What problem are you trying to solve with the rr dns?
>
> On Thu, Nov 10, 2016 at 10:48 AM,  > wrote:
>
>> Case:
>>
>> I have two services (A and B) that wish to talk to each other using 
>> akka-remoting over artery.
>> Each service executes on it's own machine behind a load balancer mapping 
>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>
>> For A to talk to B, we can for example execute:
>>
>> // Make request from an A to a B
>> val b = context.actorSelection(s
>> "akka://$systemName@$B:$port/user/$actorName")
>> b ! Request()
>>
>> where $B is the load balanced address that is resolved to a B instance 
>> (maybe B1, maybe B2.. etc)
>>
>> In order for B to receive this message, B would need to have an akka conf 
>> with canonical.hostname = $B. Otherwise artery will filter out these 
>> messages...
>>
>> So far, this works. However, now let's say this is bidirectional 
>> communication. 
>> B wants to reply to A's requests, but also, B wants to send its own 
>> independent requests to A and expect A to reply back to B.
>>
>> B would then have something like the following code
>> // Reply from B back to A
>> def receive {
>>   case  Request() => sender() ! Reply()
>> }
>>
>> But because A has canonical.hostname set to $A, which is a load balanced 
>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>
>> To work around this, all I can think of is to let each actor resolution 
>> actually do a manual dns lookup before calling context.actorSelection.. and 
>> write the explicit resolved address of each actor to their own akka conf.
>> *Is this conclusion correct?*
>>
>> I suspect akka.tcp does not have this problem as sender() would just 
>> re-use the existing tcp connection, but artery being build on udp, will 
>> suffer from the problem above.
>> Am I missing something? :)
>>
>> / Johan
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> √
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

2016-11-10 Thread Viktor Klang 
the host needs to be a stable identifier.

What problem are you trying to solve with the rr dns?

On Thu, Nov 10, 2016 at 10:48 AM, 
wrote:

> Case:
>
> I have two services (A and B) that wish to talk to each other using
> akka-remoting over artery.
> Each service executes on it's own machine behind a load balancer mapping a
> dns name, e.g. $A resolving -> multiple IP addresses.
>
> For A to talk to B, we can for example execute:
>
> // Make request from an A to a B
> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$
> actorName")
> b ! Request()
>
> where $B is the load balanced address that is resolved to a B instance
> (maybe B1, maybe B2.. etc)
>
> In order for B to receive this message, B would need to have an akka conf
> with canonical.hostname = $B. Otherwise artery will filter out these
> messages...
>
> So far, this works. However, now let's say this is bidirectional
> communication.
> B wants to reply to A's requests, but also, B wants to send its own
> independent requests to A and expect A to reply back to B.
>
> B would then have something like the following code
> // Reply from B back to A
> def receive {
>   case  Request() => sender() ! Reply()
> }
>
> But because A has canonical.hostname set to $A, which is a load balanced
> address, the reply could end up at A1, A2 or any Ai for that matter.
>
> To work around this, all I can think of is to let each actor resolution
> actually do a manual dns lookup before calling context.actorSelection.. and
> write the explicit resolved address of each actor to their own akka conf.
> *Is this conclusion correct?*
>
> I suspect akka.tcp does not have this problem as sender() would just
> re-use the existing tcp connection, but artery being build on udp, will
> suffer from the problem above.
> Am I missing something? :)
>
> / Johan
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.