I'm working on a problem, in which i have some real time weather information of different cities through out the world. I'm exposing subscribe function to interested people/clients, with input:- location(this would be the name of the city) and time(HH::MM::SS).

Now, lets suppose, N number of people subscribe for Location=>(Paris) and time=>(20:10:17). Then, how can i publish/notify N of subscribers at exactly 20:10:17 for Paris location. I' mean if iterate over the list of subscribers, then, this list processing itself would take delta time, some subscribers would receive information with delay.

What data structure should i use, e.g, list, map or vector etc, and how should i process it, i mean, threading model, so, that, i could be able to publish information to N number of subscribers at the same time with out any delay?

edit: Resolution is upto seconds, i mean, mili seconds delay is ok. And, server hardware capable of running Millions of threads.

  • 6
    Somehow, I rather suspect that the iteration time over the data structure being used will be dwarfed by the time it takes to actually send any of this stuff. Indeed, just the time needed to push the data out to those "millions of threads" would probably overwhelm the iteration costs. Jan 15, 2019 at 15:46
  • 1
    I don't have an answer in mind, but to clarify: do you want to finish all notifications as fast as possible, or do you want minimum difference between the first and last notification even if that delays the whole batch? I.e. are you looking for maximum performance or maximum fairness? Jan 15, 2019 at 16:20
  • 6
    What is the actual problem that you try to solve? Weather data typically isn't time-critical, getting it 15 seconds later than somebody else doesn't really matter. Either your actual problem is not weather data, or you made an unreasonable promise about your service which is hard to keep. Jan 15, 2019 at 16:53
  • 1
    "communication obviously take time, so we have to process each and every subscriber in different thread" -- this is actually a terrible idea. IO bound tasks should be handled asynchronously. You can break up the overall processing into a few threads, but the context switching overhead would eat you alive here. Jan 15, 2019 at 20:41
  • 2
    What's the requirement here? Is it that you get your message to N subscribers within a certain amount of time after finding out you have a message to send? Or is it that every human gets the notification at exactly the same time?
    – Blrfl
    Jan 16, 2019 at 4:21

2 Answers 2


Warning: This may not be a practical answer to your problem (but then again, it may be).

In an ideal world, you'd use multicasting for this job. The basic idea of multicasting is that routers (which, by nature, know about routing) handle the job of routing messages to your clients. The clients enable that by registering with a router to tell it what they want to subscribe to.

The good point of this is that you can send a message to all the subscribers by sending a single message to the correct multicast address on the router. The router then forwards that message either directly to subscribers or to the multicast addresses on other routers (which can, in turn, fan it out to still more clients).

If you're doing this over private infrastructure (possibly including some tunnels over public infrastructure), it may take some effort to get all the routers involved properly configured to do the job right. In particular, it's actually fairly common for the default configuration on a lot of routers to simply block all multicast packets (which will obviously stop it from working, at least via that router).

If you need to use public infrastructure, the problem is probably pretty obvious: some of the routers your data goes through may well block multicast packets--and in this case, you have no control over how the routers are configured, so if it doesn't work, you probably can't do much (if anything) to fix it. Worse, even if it works part of the time, the minute routing changes (again, something over which you generally have no control) it may break.

There is some hope though. In particular, although IPv4 does support multicast to a limited degree, it was tacked onto the side (so to speak) long after IPv4 was originally defined. As such, if you're (exclusively or even primarily) using IPv4 infrastructure, it's pretty unlikely that you can get multicast to work over public infrastructure.

Multicast has been part of IPv6 from the beginning though. IPv6 doesn't support broadcast at all, only various forms of multicast. As such, for connections where both the server and the client support IPv6, there's at least a decent chance that you can also use multicast (quite a bit better chance than if either is restricted to IPv4, anyway).


  1. https://www.rfc-editor.org/rfc/rfc3956
  2. https://www.rfc-editor.org/rfc/rfc6308
  3. https://serverfault.com/questions/393752/is-ipv6-multicast-routable-over-the-internet

I know I should not ask for clarification, but it is hard to answer on this question having such high requirements.

Having good hardware, it takes ~400ns to send one UDP message. 400 * 1mln = 400ms just for sending. But I guess you need to guaranty notification delivery, so you have to listen for incoming 1mln messages. Then by timeout send notification again. Meanwhile I guess you have to send next portion of notifications for other clients. As @Jerry Coffin mentioned, you can use multicast. But it has limitations. So probably you have to use TCP or "UDP with delivery guaranty" protocols.

So to make right decision you should provide more details:

  1. How many clients do you have in total?
  2. Do they connect from same network or use NATs?
  3. What happens when client receive notification? Does it subscribe again? Or it subscribes to receive one notification only? Or it subscribes to receive update every N seconds?
  4. Do you need notification delivery guaranty?
  5. How often do you expect your server will send notifications?
  6. How many cities you have to serve?
  7. Do you send just temperature or other data also? i.e. can we send one packet with temperature for many cities. IMHO it makes no sense to send temperature just for one city. You will not utilize MTU.
  • // I know I should not ask for clarification // In my opinion, on this site you should definitely ask for clarification. Many times, question asker had a real need but the question was framed poorly or only marginally relevant to the real need. Clarifications help both sides (asker and answerer) identify the real need. The question asker has the responsibility to update the text of the question (but should not completely change the nature of the question) once others have helped clarify.
    – rwong
    Jan 20, 2019 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.