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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,57893ac51069959a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.213.68 with SMTP id nq4mr319087pbc.2.1327515065407; Wed, 25 Jan 2012 10:11:05 -0800 (PST) Path: lh20ni223203pbb.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Wed, 25 Jan 2012 19:10:56 +0100 Organization: cbb software GmbH Message-ID: <1fir2dvz9hasf$.wk7qxfxjkp9a$.dlg@40tude.net> References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> <2c51ce87-87ef-438c-bec5-e3b8114f0471@cf6g2000vbb.googlegroups.com> <1rp216zwnjx3j$.rjwu8m3hxgp1.dlg@40tude.net> <78412bc2-abc1-4d69-a949-487ce070a8de@o13g2000vbf.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: CNp+VBSYV+ysZXOiVRxJxw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-01-25T19:10:56+01:00 List-Id: On Wed, 25 Jan 2012 07:05:57 -0800 (PST), Ada BRL wrote: > Just a question: > If I have understood well, I may have just one thread connected with N > clients through N sockets, using the SAME PORT. As well as from different Ethernet ports. Reading from one port using multiple tasks is unlikely to give any performance advantage. But if you have, for example a 4-port Ethernet controller, you might wish to assign a separate task for each port. > How may I know if one client (say number 5) is connected or not? I > need an array of connections and so on... Each connection has a socket. Connected/not is a state of a TCP/IP socket. > In the case of N readers I can know it, because there's a mapping one- > to-one. > > In the case unique reader with N sockets, the OS (in my case MS > Windows 7 Pro) handles the concurrent requests of sending data to the > reader queueing them and delivering each request per time to the > (unique) reader. Select() returns list of sockets available to read without blocking. You go through the list reading the data and pushing them further. Typically, you have a state machine associated with each input socket. The machine is fed by the input: often, just one octet, because you don't want to get blocked due to a protocol error. The state machine swallows the octet and depending on its internal state and the octet performs a transition accumulating data as necessary. At some point it queues a request to the server. > I MUST BE SURE that the data is delivered to the server...what do you > suggest me to do? Multiple readers or only one? Delivery is guaranteed (for TCP) and not guaranteed (UDP) independently on the way of reading. Multiple readers is simpler to implement, so you should try this first if the number of sockets is bearable. >> You could consider protected objects, as others already suggested. The >> reader might simply queue the packet read and continue, rather than waiting >> for a rendezvous with it. > > Regardless to the unique reader / N readers, I have to use a protected > object that incapsulates a buffer (implemented by an array of strings type); When readers perform some preprocessing, then elements of the buffer (queue) should likely be something more advanced than mere strings. > the reader(s) write into this protected buffer and the server reads from it. > Am I right? Protected objects implements mutual exclusion by > construction. Yes, it is called "protected action." Waitable operations are entries, like in the case of tasks. Instant operations are procedures. Functions access the object in a way that guaranties coherence. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de