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.

  • 5
    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. – Nicol Bolas Jan 15 at 15:46
  • 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? – Jacob Raihle Jan 15 at 16:20
  • 5
    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. – Hans-Martin Mosner Jan 15 at 16:53
  • @JacobRaihle communication obviously take time, so we have to process each and every subscriber in different thread. Also, Ideally requirement is to process all subsribers at exact time, but, practcally i think minimum delay would be ok i guess. – user1372771 Jan 15 at 17:45
  • 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 at 4:21

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://tools.ietf.org/html/rfc3956
  2. https://tools.ietf.org/html/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. If you really have more than 1mln clients and you want to use TCP, then you need more than one server, as one server cannot maintain more than 65k TCP connections simultaneously.

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 at 10:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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