From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: New IEEE Language Popularity Ratings
Date: Wed, 10 Aug 2016 15:55:45 -0700
Organization: A noiseless patient Spider
Message-ID: <87d1lg1bf2.fsf@jester.gateway.pace.com>
References: <31c22983-150c-4dab-abba-588e15f75914@googlegroups.com>
	<nnd708$fvc$1@dont-email.me>
	<ptqdnX3AXc9IqDfKnZ2dnUU7-IfNnZ2d@giganews.com>
	<noegdm$kdo$1@gioia.aioe.org> <87y44514hl.fsf@jester.gateway.pace.com>
	<noeq9c$s8p$1@dont-email.me> <87twes1v4l.fsf@jester.gateway.pace.com>
	<nofkv0$dhm$1@gioia.aioe.org> <87popg1n4b.fsf@jester.gateway.pace.com>
	<nofu7d$srl$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="590ea01354cf4bcbcd857d7ebbd88128";
	logging-data="15117"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/Gc3wy4bz1HrlebsL+kB4z"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:UrJjK90VLeABoGDbyEOBPOknGB0=
	sha1:oNyfVDqU/rH5zFn6q8C0bgPy0+g=
Xref: news.eternal-september.org comp.lang.ada:31372
Date: 2016-08-10T15:55:45-07:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Client is a small board that has issues with load and multiple
> connections. 

If it has a TCP stack (and hopefully a TLS stack these days), it's not
THAT small.  It can deal with pushing something every few minutes.

> but there is no guaranty that the server pulls data or ready to be
> pushed with data in time. That is how it is similar to real-time.

There might be no server connection at all (forgot to pay ISP bill).
Either the client has to store data for later retry, or has to drop data
that can't be uploaded in a reasonable amount of time.  Neither of those
is anything like realtime in the traditional sense of something like
motor control.

> It is a big deal because clients are slow, that inflicts latencies
> accumulating on the server side. Then if you start 30k threads your
> server will freeze. Then it is not really scalable because there are
> usually databases and web portal behind.

An IOT thing would usually use a simple service that doesnt send whole
bloated web pages, and with 30k connections you wouldn't use an OS
thread for each one.  Async frameworks like node.js can handle that load
easily, or lightweight processes like in Erlang can also do it.  See the
famous "C10k Problem" article from 1999 and realize how much has
happened in hardware and software since then.  Scripting languages on
today's hardware are much faster than C was on 1999 hardware.  The db
would be something like redis which can easily handle 1000s of updates
per second.  Many giant web sites are written in scripting languages:
Wikipedia (PHP), Youtube (Python), Paypal (node.js), Facebook (a
compiled version of PHP), Yelp (Python), Reddit (Python), Github (Ruby),
etc.  A usual IOT server is far more lightweight.