Network Infrastructure

MoPub Marketplace IPs

RTB traffic from the MoPub exchange will come from the following IP blocks:

  • 192.48.236.x
  • 192.48.237.x
  • 199.16.157.x
  • 69.12.56.0/21 [will be deprecated – TBD]
  • 64.63.0.0/18 [New]
  • 188.64.230.0/24 [temporary new addition]
  • 188.64.231.0/24 [temporary new addition]
  • 192.44.69.0/24 [temporary new addition]
  • 199.59.150.0/22 [temporary new addition]
  • 199.16.156.0/22 [temporary new addition]
  • 199.59.148.0/22 [temporary new addition]

Connections

  • DSPs should connect to our servers using HTTP/1.1 with persistent connections (keep-alives).
  • DSP endpoints should only use either the standard port 80 OR 443 for receiving MoPub traffic. If you want to use a different port, please escalate separately with your respective commercial contact.
  • Keep-alive timeouts are required; recommended timeout value between 60-120s.
  • All bid requests are sent to your endpoint via an HTTP POST method, not an HTTP GET method.
  • MoPub does not explicitly send “keep-alive” in bid request header per the http/1.1 RFP.
  • MoPub does not support HTTP/1.1 pipelining
  • MoPub does not support TCP fallback.

More background on connection logic

  • The opening/maintaining/closing of connections is an extraordinarily fluid and dynamic process that is determined by a number of variables (inbound requests, response times, current open connections, etc) that can fluctuate wildly on a millisecond by millisecond basis. As such, it is not realistic to simplify the number of open connections as a function of QPS
  • Generally speaking, the following rules of thumb apply:
    • As your QPS increases, MoPub will attempt to open more connections
    • As your bid response latency increases (time required to respond to a bid request), we will attempt to open more connections
    • MoPub will never wait for a connection to become free (ie: new connections are opened as needed because this is a real-time application)
  • MoPub will close connections if either criteria is met:
    • No response received > 300ms (ie: connection timeout after 300ms, 180ms if using APAC POP)
    • > 5 unused/open/free connections exist at any given point in time
  • General overall rule of thumb – The faster you respond to bid responses, the higher the chance that we will reuse an existing connection vs opening a new one. Decreases in open connections can likely be attributed to a combination of decrease in QPS and a decrease in bid response latency.

Gzipping (compressed bid requests)

Background

MoPub supports gzipped requests/responses on the Marketplace exchange. Gzipping compresses requests and responses so less bandwidth is required to manage your integration with MoPub and thus reduced bandwidth costs for both of us. Partners who have enabled this feature have seen upwards of a 30% reduction in bandwidth.

Sending back compressed bid responses

  • DSPs have the option of sending back non-compressed OR compressed (gzipped) bid responses even if your bidder has not been enabled for gzip.
  • The below header is included in all MoPub bid request traffic indicating that the bidder has the option of responding with a gzipped response

      Accept-Encoding: gzip
    
  • Action required from DSP: Adjust your bidder’s HTTP configuration to ingest the ‘Accept-Encoding’ header and behave accordingly

Accepting compressed bid requests

  • DSPs have the option of receiving compressed bid requests from MoPub. In order to opt-in, you must reach out to your account manager.
  • By default, all DSPs receive NON-compressed bid requests unless enabled by a MoPub team member
  • If your bidder has been enabled to receive compressed bid requests; the below header will be included in all MoPub bid request traffic:

      Content-Encoding: gzip
    
  • Action required from DSP: If you would like to take advantage of this; please contact your account team or dspsupport@mopub.com to request enablement of gzipped bid requests.
  • Once enabled, please monitor your systems carefully to ensure your setup is properly ingesting these newly gzipped requests and there is no bidding/spend disruption

Additional Resources

Infrastructure

  • It is highly suggested that you use load-balancers as your main entry point for all traffic.
  • Round-robin DNS as a pseudo load-balancing solution is strongly discouraged.
  • The disadvantages of Round-robin DNS for high throughput applications such as RTB are described in the Round-robin DNS drawbacks article on Wikipedia.

DNS Best Practices

  • CNAME records (returned from your bidder endpoint’s DNS lookup) should never point to another CNAME record.
  • Maximum DNS reply size of your bidder endpoint must not exceed 512 bytes (typically 13 A records)
  • Note that DNS replies < 512 bytes (< 13 A records) dramatically increases the likelihood that MoPub traffic will be improperly sent to old/stale subnets for your endpoint in addition to other unexpected traffic issues.
  • Max DNS reply size of < 512 is recommended per DNS-OARC

Immediate-term action items for escalating infrastructure/network issues with MoPub

1. Loop in your Account Manager/Director

2. Collect all information below

* Please describe in detail the issue you are experiencing. Please include all relevant logs, graphs, packet captures, etc.
* Please describe in detail any environment changes made around the time of incident. (software changes, infrastructure changes, capacity increases, etc.).
* Are you seeing this behavior with other partners?
* When did you notice this issue begin?
* Please include date and as specific a time as possible.
* How was this issue detected?
* Is this issue sporadic or consistent? If sporadic, please quantify the duration, frequency and intensity of these events.
* Timestamps of these events (optional, but strongly recommended for quicker troubleshooting).
* Regarding your infrastructure setup, please detail the following:
    * Please provide your bidder endpoint and number of DNS A records it is pointing to.
    * How is your load balancer configured?
    * Do you use HTTP/1.1?
    * Does your endpoint receive traffic from other exchanges?
    * Do your servers share traffic with other exchanges? Or dedicated exclusively to MoPub traffic?
    * What bandwidth dedicated to MoPub?
* Please run a tracert to the following IPs and include the results:
    * 192.48.236.x
    * 69.12.56.0/21

FAQ

1. Where are MoPub’s Marketplace datacenters located?

United States, East Coast

2. Can you share the IP addresses of MoPub’s servers so we can whitelist the IPs on our end?

  • 192.48.236.x
  • 192.48.237.x
  • 199.16.157.x
  • 69.12.56.0/21
  • 69.12.56.0/21 [will be deprecated – TBD]
  • 64.63.0.0/18 [New]
  • 188.64.230.0/24 [temporary new addition]
  • 188.64.231.0/24 [temporary new addition]
  • 192.44.69.0/24 [temporary new addition]

3. What port(s) is my endpoint allowed to use to receive MoPub traffic?

  • DSP endpoints receiving MoPub traffic are required to use either the standard HTTP (80) or HTTPS (443) port.
  • Using ports other than the two listed above will result in your endpoint receiving zero traffic.
  • If you would like to use a different port for your endpoint, please escalate separately to your respective commercial contact on the MoPub side.

4. What is a POP? How does this differ from a data center?

A point of presence (POP) is an endpoint that is located locally in order for DSPs to connect to. This is not a full fledged data center. Our POP endpoint does not store any data or make any ad serving decisions. Instead it redirects bid responses from DSPs to our data centers in the United States. If you would like to leverage our APAC POP please reach out to dspsupport@mopub.com for additional details.

5. What is MoPub’s max latency cap when responding to a bid request?

Maximum allowed round-trip time for any given auction is 300ms (180ms if using APAC POP). Round-trip time is defined as the aggregate latency required for:

  • Latency between MoPub sending a bid request and your servers receiving it
  • Latency overhead associated with your servers ingesting and processing the bid request
  • Latency between your servers sending back a bid response and MoPub’s servers receiving it

6. How can I tell what our round-trip latency is?

We can provide this for you! Please email your account team or dspsupport@mopub.com for this information.

7. How can I verify if I am timing out?

Please email your account team or dspsupport@mopub.com and we can get you this info.

8. Why am I seeing empty POST requests from your servers?

Your servers may be explicitly looking for the keep-alive header in our HTTP POST requests and improperly assuming that the lack of keep-alive header indicates a zero-length request.

Per the HTTP/1.1 RFP, explicit keep-alive headers are not required. Keep-alive should always be assumed as TRUE.

9. What HTTP headers does MoPub require in the response?

For HTTP 200 bid response headers we require the “Connection”, “Content-Length” and “Gzip” headers. Gzip is only required if the response is compressed. All other HTTP responses (204) do not require HTTP headers.

Last updated October 22, 2018

TWITTER, MOPUB, and the Bird logo are trademarks of Twitter, Inc. or its affiliates. All third party logos and trademarks included are the property of their respective owners.

© 2018 MoPub Inc.