F3llony
-
Posts
1,353 -
Joined
-
Last visited
Posts posted by F3llony
-
-
Protams, bet to visu manā vietā dara socket.io. Man pusē, atkrīt, tam visam sekot līdzi :D
Man pēc Http Requestiem, socket.io atgādina maģiju. Atpakaļ mani nekas neiestums. Tas pats ar React, ja kaut kas ir lielisks, gribas nošauties, ja jālieto kas cits.
Nu nu, maģija - viss, ko tavā vietā izdara socket.io šajā kontekstā ir izsauc JSON.stringify un JSON.parse otrā galā. Viss. Izlasi manu pēdējo postu iepriekšējā lapā... Nemaz vairs neliksies tik maģiski. It īpaši ja tādam loopback piekabina klienta pusē piemēram, vai nu angular-sdk vai kaut kādu restful.js
Tieši tā - nedaudz smukāks un kā jau iepriekš minēja nav jau visi tie paši plusi un mīnusi, tieši tās atšķirības viņu padara savādāku un daudzos gadījumos noderīgāku.
Nekādu īpašu atšķirība no programmētāja viedokļa starp parastu TCP socketu un websocket nav. Kā tas tehniski strādā "zem motora pārsega" Wuu gan jau maz interesē. Un arī tur, kas tad tik ļoti atšķiras? Handsheiks? Okei. Katrai envelopei ir izmērs un piederība. Nu labi, nevajadzēs skaitīt saņemtos un nosūtītos baitus. Vairāk nekas tur arī nav... Fundamentālas problēmas, kā bija ar TCP tā ir ar websocketiem. Par ko arī ir runa. Tāpēc arī mums ir viss HTTP - tieši lai izvairītos no šīm fundamentālajām problēmām.
-
Skaties,
Clienta pusē
Vārds, objekts, callback
io.emit('transfer', {func: '/user/logout', key: this.data.__session__key}, (data) => { //Daram ar 'data' ko gribam })Server pusē,
callback({ko vēlamies nosūtīt})Un tas uzreiz izdarās klienta pusē, būtībā nosūtam funkciju. :)
Ērti! Tev nevajag clienta pusē taisīt klausītājus. Tāds vienkāršs get, vien sanāk. Un var nosūtīt Javascript objektu/arraju kāds viņš ir, nevis JSON.stringify() un JSON.parse() turpu, šurpu.
Nezinu, varbūt ar HTTP tāpat var, neesmu redzējis, ka kād stā darītu, visur piedāvā jsonu konvertēt.
Būtībā, no mongo paņem arrayu un pa taisno viņu nosūti, kāds viņš ir.
Es kad atskatos, kā es šo daru ar PHP API un Ajax req... #%^&*#@(*#@*!!!#@
socket.on('transfer', (req, res) => { UserSchema.find({}, (err, docs) => { res(docs) //Pa taisno nosūtam uz clientu }) })Ā, un tu domā kā socket.io to JSON array nosūta klientam kaut kādā citā, maģiskākā veidā? :D JSON.stringify un JSON.parse, tikai paslēpts no tevis, tādā pašā veidā kā jebkurai normālai HTTP bibliotēkai... Un nekādu funkciju tu nekur nesūti...
Tam pašam pretīgajam jQuery $.get('/wat/', (data) => { console.log(typeof data); }) ja serveris atgriezīs application/json no /wat/, data variablis arī būs JSON objekts jau.
Socket.io nav nekāda maģija. Klientiem, kas neatbalsta websocketus, socket.io vienalga fonā izmanto tos pašus XHR pieprasījumus...
-
Socketu plusi:
- socketiem nav jāgaida konekcijas izveidošana, kas pie bremzīga tīkla aiz n-tiem firewāliem aizņem reāli jūtamu laiku, tāpēc aizture ir mazāka.
- socketiem var sūtīt datus no servera, negaidot, kad klients tos paprasīs. Tas ir liels bonuss.
- sockets var sūtīt binārus datus, kas atkarībā no situācijas, ļauj samazināt datu plūsmu pat līdz 5 reizēm.
Tas, ko esmu pamanījis, ka arvien vairāk un vairāk parastas web appas, kuras varētu iztikt bez tā, izvēlas websocketus, jo ir daudz bonusu.
Viena kaste var mierīgi turēt 100k - 1M atvērtu konekciju (atkarībā no tehnoloģijas kādu izmanto). Tas ne tuvu nebūs bootlnecks web sistēmai.
- daļēji patiesība (it depends). Un pat ja būtu pilna, tas būs pamanāms vienīgi tad, ja būs pieklājīgs rec/s. Vienam updeitam x300 gados ieguvums būs nekāds...
- obviously. Tas jau tika minēts.
- ??? un HTTP nevar?! Tas ir kā, visas manas kaķu bildes značit transportē Somālijas imigranti?!
Tas ko tu esi pamanījis ir kaut kāda figņa, kārtējo reizi. Jo te būs websoketu mīnusi:
- ping/pong vēl jorpojām nav
stabilasnekādas standarta implementācijas - dcon events nav uzticams - ja klients vienkārši "aiziet prom", neemitējot dcon, tu par to uzzināsi tad, kad iztecēs taimauts - ja tas netiek pareizi apstrādāts, tevis sūtīto ziņu klients probably nesaņems. Ever.
- socket.io automātiski diskonektē/rekonektē pie taimautiem un idlē. Socketiem IR jāgaida konekcijas izveidošana, dotajā gadījumā pie zema rec/s socket.io nav nekāda ieguvuma pret xhr, izņemot iespēju sūtīt info no serverside, kas ne vienmēr vispār ir vajadzīgs.
- Websocketiem nav natīva ACK. Socket.io ir kaut kas līdzīgs ACK, bet vienalga diezgan rupjā veidā un pašam jāatseko vai ziņa tiešām līdz klientam/serverim ir nonākusi. CRC ftw, yayy! :D
- Paralēli xhr pieprasījumi? 2-6 tredi uz katru mērķa domēnu, atkarībā no pārlūka. Paralēli websocket pieprasījumi? 1 uz katru socketu. Un pamēgini iestumt websoketā tādu palielāku message, redzēsi kas notiks ar visām tām, kuras sekos...
Viena kaste var turēt 100k-1M atvērtu konekciju, for sure. Tā pat, kā Nginx pilnīgi noteikti var nodrošināt 1M rec/s, ja viss, ko mēs sūtam šurpu turpu ir "Hello world"...
Visi kaut kā ierauga, oooo, cik skaists websocketu api/socket.io etc. bet pamanās piemirst, ka websocketi nav nekas daudz vairāk kā nedaudz smukāk iepakots TCP sockets. Ar visiem tiem pašiem plusiem. Un visiem tiem pašiem mīnusiem (+ some).
-
Baigi ērti piejūgt pie Flux storēm un pušot atjauninājumus/notifikācijas, un ir daudz ērtāk strādāt, ja clients ir uz Javascripta uzrakstīt. Sūti pa taisno objektus, bez jebkādas konvertācijas JSON un atpakaļ uz objektiem.
Cik studēju, atvērts sockets neprasa ēst. Kad pamēģini pastrādāt ar socket.io, galīgi nav vēlmes iet atpakaļ uz akmens laikmetu. Protams milzīgām lapām, tas nav variants.
Huh? Pirmā daļa - jā, tam tas arī ir paredzēts. Par konvertāciju - vari sīkāk, kas tev kur jākonvertē? Gan websocketi, gan HTTP ir tikai transports. Atšķirība tikai tajā, ka HTTP ir con=>message=>data=>dcon, bet websockets ir con=>message=>data=>message=>data=>(...)=>dcon.
Atvērts sockets ir atvērts sockets un ēst prasa tik pat daudz kā jebkura cita atvērta konekcija. Un tava kaste nevar turēt infinite daudz atvērtu soketu. Pat ja tavs apmeklētājs neko nedarīs, bet turēs lapu atvērtu - tavs sockets vienalga karāsies atvērts. Ja tu jamo virini manuāli - zūd visa soketu jēga.
-
Loopback izskatījās ok, līdz gribēju piejūgt socket.io. Nepavilku. Ja vajag prastu REST api, tad gan baigā bomba un ērtība.
Jo Loopback tam nav paradzēts. Socket.io ir reāl-laikā barot kaut kādus datus. Darbam ar dokumentiem un CRUDam socket.io nav vajadzīgs, un nav pat vēlams. Priekš kam tev atvērtus soketus turēt ja tev viens klients atsūta varbūt vienu updeitu reizi minūtē.
-
Bookshelf.js. Ja būvē kaut ko lielāku, iespējams ir jēga skatīties uz kaut ko līdzīgu loopback.io
-
Par battle tested - a Laravels nav? Kas par tiem 6+ gadiem? Laravel nu jau ir 4+ gadi. :) Un ko man dod tie zinošie čaļi, es tak ne viņus pazīstu, ne arī kādreiz pazīšu. Neba nu ierakstīšu forumā jautājumu un tas guru pats personīgi man pēc 5 minūtēm būs safixojis problēmu.
Man pats Doctrine liekas pēc vēmekļa, bet nu tas subjektīvi. Bet kāda vaina analogiem Laravelā?
Kas attiecas uz apakšsistēmām, tad man, tieši otrādi, ir pārliecība, ka tam ir jābūt sastāvā. Tā taču ir visa FW jēga, ka tev ir pieejamas visādas kopā sajūgtas pamatlietas, par kuru implementāciju tev vairs nav jādomā. Pēc nejaušības principa kopā samestas paciņas nav FW.
Ja pie kaut kā ir jāpierod, tas tas, visdrīzāk, nav nekas labs. Nu jā, pēc 3 mēnešiem Stokholmas sindroms klāt. Nejaukt ar to, ka ir acīmredzami laba lieta, ko tu vienkārši vēl nezini, tāpēc kādu laiku ir jāpamācās to lietot.
Es domāju battle tested 6 gadus ilgāk, kā Lara. Symfony iznāca 2005ajā.
Zinošie čaļi dod to, ka jami konstanti kaut ko labo un uzlabo freimā, kuru Tu lieto. Un pēdējais par jautājumu forumā, vispār jā, tā tas arī strādā - liela daļa no tuvu 100 pilsoņiem vairs pat neatminu cik valstīs kam algu maksā Sensio, plus X skaitlis no citiem kantoriem (piem. Smile, ORO, Magento, eBay Enterprise) ar to arī nodarbojas. Jā, tici vai ne, ir bars indivīdu kuriem maksā tieši par to, ka jamie raksta forumos un labo bugus. Who could have thought...
Lara, on the other hand ir +/- 1 pilsoņa šovs kuram nav praktiski nekāda nopietna backing, vismaz publiski nekas tāds nav izteikts - un pēdējo reizi kad čekoju, merge rights (vismaz merge approval) bija tikai Otwellam (I might be wrong on this tho). So, ja tu tici kādiem dieviem, ir laiks lūgties lai jamo vienā dienā nenobrauc kāds autobuss :D
Un tad vēl ir tādi brīnumi kā šis epic. Because fuck you and fuck your API stability. :D Un tādu ir vēl - tur visādi dīvaini versiju bumpi, pēkšņi kaut kur pazūd vai mainās publiskas API daļas, kaut kādas klases pēkšņi pārvācas velns zina kur etc.
Doctrine piemēram tieši pieder pie tām lietām, kas ir obviously laba un pie kuras jāpierod. Savukārt Eloquenta Modelī ar 3000+ sloc es gan neko labu īsti nesaskatu. Par to, ka value object entitijas vietā katra entitija ir full blown query buildereris es nekomentēšu...
Par apakšistēmām - kam tev dependency menedžeris? Standard issue freimworkam ir jābūt vaniļai, nav jāsatur visa iespējamā tufta ko nu kāds kaut kur varētu izmantot - tā vietā ir jānodrošina iespēja to pielikt klāt pie nepiciešamības, bez sviedriem un asarām.
-
Tieši tā paša iemesla dēļ, kāpēc vajag programmētāju imho... :D
-
-
Reāli gribētu zināt īstos iemeslus, kāpēc. Kas nez varētu būt tāds, ko var izdarīt ar symf, un nevar ar laravelu, vai arī kas tur ir ērtāks.
Nepatik route'ošana, vai?
Middleware?
Kontrolieri taču ir plikas klases, ir dots PSR4 autoloaderis, eloquent neviens nespiež izmantot, viss principā ir uztaisīts, ka tu vari darīt kā vēlies, organizēt kodu velns viņu zina kā.
Nez, nez, atteikties no forša komandrindas rīka, jēdzīga queue, normālām migrācijām, u.c ērtāk lietām...
Vairāki iemesli - sy ir paredzemāks zem slodzes jo kodola elementi ir battle tested un pielaboti jau gadiem (runa ir par platformu ar >100m apmeklētāju), ekosistēma ir daudz attīstītāka un stabila (+6 gadi history), KB ir probably plašāks, ir daudz vieglāk atrast programmētajus kas jēdz Symfony kā tos, kas jēdz Lara, community ir liels procents ļoti zinošu pilsoņu (Jordi Boggiano, Ocramius, Christophe Coevoet, Schmittjoh, pats Fabiens to name a few) un nesamērāmi lielāks corporate backing, kas nozīmē ka izmaiņas un jaunas lietas sekos kaut kādai loģikai, nevis kā Laravel core devi jūtas konkrētās dienas rītā, kas atkal dod punktus pie stabilitātes.
Par rīkiem - kas vainas Sy console, Doctrine migrācijām? Queue? Freimam manuprāt vispār nevajadzētu bāzt degunu queue un citās analoga līmeņa apakšsistēmās.
Lai kādi mīnusi arī Laravelam nebūtu šobrīd atrodami, aizstāt Laravelu ar Symfony - tas ir kā konfekšu vietā sākt ēst labi nogatavojušos caureju.
Es tā jutos tieši pirmos 3 mēnešus kad sāku ar Symfony. Vēlāk pārdomāju...
-
Par to phantom nemācēšu spriest, bet gan jau bija kāds iemesls, kāpēc tas tika iekļauts.
Jo Otwells nezināja par wkhtmltopdf un dompdf? Sarkasms. Problēma jau nav fantomā, bet gan faktā, ka pie pakas install tev novelkas visi binary, pofig kāda platforma... Baigi grūti jau uzrakstīt composer post-install skriptu.
Nu, nu, kur tad viņi pārvācās?
Nule pagājušā gada beigās viens "konkurentu" kantoris pārvācās uz Symfony2 un nule jau esot uz 3.
Bet nu tomēr tas, ka, izpildot vienu konsoles komandu, tev ir jau gatava ekosistēma ar pilnīgi visu, gan kodu, gan palīgrīkiem, lai varētu sākt bliezt, tas ir lieliski. Nē, nu var jau arī pats savilkt paciņas un salikt savu custom setupu, bet nu kam tas vajadzīgs, ja var novilkt jau ejošu.
http://symfony.com/doc/current/book/installation.html
symfony new kavacky-recepshu-lapa
Boom.
-
Arvien vairāk pēdējā laikā pārliecinos, ka Laravel ir jaunais Wordpress - t.i. jamo pa lielam pasākuši lietot un fanot par tie, kuriem gar kodu nevajadzētu grābstīties vispār.
Ekosistēmā un kaut vai tajā pašā Laravelā ir diezgan daudz visādu wtf un rodas iespaids, ka pakalyst drīz būs kaut kas līdzīgs pēc kvalitātes wordpresa pluginu miskastei.
Un tad vēl protams liela problēma ir pats Otwell's, kurš pats ievieš visādas greizas un reizēm galīgi tupas "fīčas" for the sake of "convenience", kas ne vienmēr vispār ir convenience - piemēram, kaut kad pasen Ircmaxelis sakliedza par security, es kaut kādā brīdī šitādu 50MB fantoma kluci atradu velkamies līdzi katram cashierim iekš L5 https://github.com/laravel/cashier/tree/5.0/src/Laravel/Cashier/bin, da i pabrovzējot sourci reizēm liek aizdomāties vai Lara tiešām ir kaut kas uz kā bāzēt kaut ko nopietnāku par Kavacky brokastu recepšu blogu...
Līdz ar to nav arī brīnums, ka dzird tos, kas sākumā dikti fanoja par Lara pārvācamies kaut kur citur.
Was good while it lasted...
-
-
Piemēram, tas pats Techcrunch darbojas uz Wordpress un pirms pāris gadiem tika pārdots par 30 miljoni - tas ir naudas daudzumu, kura 1% ir vairāk nekā tev visā dzīvē samaksāts par tavu kvalitatīvo kodu.
1% no 30,000,000 ir 300,000. Pēc CV.lv 2015.g. datiem, vidējais statistikais programmētājs pelna 1,200 ņešto mēnesī, kas summējas uz 14,400 ņešto gadā. Dalot 300,000 nešto ar 14,400 ņešto saņemam 20.8333333333 gadus.
Sagaidāmais dzīves ilgums Latvidžas vidējam statistiskajam pilsonim, kas pamatā izvairās bāzt galvu ārā no braucoša vilciena loga ir 74.30 gadi. Pensionēšanās vecums - 62 gadi. Pieņemot, ka mūsdienu vidējais statistikas program-meistars darbu sāk aptuveni gadu 20-25 vecumā (manis no pirksta izzīsts skaitlis), sagaidāmais darba stāžš ir 37 gadi.
Ņemot vērā to, un pieņemot to, ka Jurchika alga dzīves gaitā nemainīsies (kā tad...), patiesībā Jurchiks nopelnīs veselus 1.7760000000000002 procentus no 30,000,000 jeb 532,800 ņešto.
:D
-
Kā Roze jau teica, autentifikāciju Mongo arī nokonfigurē. Nu tā, lai dajebkurš lietotājs uz kastes nevar iepriviliģēties ;)
-
-
"Rolling mutation model is a lockless subject manipulation methodology, mostly implemented in distributed systems programming. It is usually implemented as mutable state subject and single-pipe, in memory or semi-persistant queuing system that accepts broadcasted changes to the state and redistributes given state changes back to observers while also mutating the subject itself, in a similar way how a observer pattern is implemented, but with a distinct traits of a) having a single-pipe queue b) distributing mutations, instead of state. Rolling mutation models are best used when mutation from state X to state Y requires a known, relativistic mutation, e.g. is deterministic and past state is immutable. This approach is useful when processing large amount of mutational data in highly concurrent systems, in both near-realtime systems and offline processing, as it only allows for single manager to manipulate state, hence, does not require locking." © basics of near-stateless system design, by a guy writing code that somehow manages to process millions of mutations every. damn. minute.
a = 0; +1; -1; +5; -2; +4; a?=7
Un es nevienā brīdī neesmu teicis, ka locki netiek izmantoti nevienā vietā vai lietā, bet tie ir specifiski gadījumi ar noteiktu mērķi un pamatojumu, piemēram, tranzakciju apstrādei kas nav vērtību mutācija. SO ir arī 6k jautājumu pie lock free, lai gan ko tas izsaka es toč nesaprotu. Ko tu centies ar to pateikt? Ka eksistē lokošana? Okei. Ko tālāk?
Bez tam tas, ko tu sauc par gudro sensoru, patiesībā ir mikroprocesors vai mikrokontroleris + sensors
Un kāpēc tu domā to sauc par gudro sensoru, m? Tāpēc, ka šamam ir hobijs - pankūkas cept? Par gudrajiem sensoriem dēvē tieši to un ne tikai to - tas var būt sensors + mikrokontroliers līdz pilnīgs standalone sensors + mikrokontroliers + tīkla interfeiss + lokāla DB.
OSGP sensor bus specenes pirmā versija nosaka, ka slave var iniciēt reģistrāciju, taču palasot tālāk par to vienu doku un pirmajām 3 rindkopām tu noskaidrosi, ka tā pat, kā M-Bus, arī OSGP var darboties inversi.
Un zinu to es tāpēc, ka man mājās ir 3 M-Bus sensori, kas pie izmaiņas pie noteikta thresholda or ik pēc X laika sūta datus aggregatoram čerez tcpip. Ir dažādi risinājumi dažādās valstīs dažādiem provaideriem, dažādu iemeslu dēļ. Ir sensori kas atgriež vērtības pēc pieprasījuma, ir sensori kas atgriež vērtības konstanti ar praktiski nekādu intervālu un ir tādi, kas paši reportē.
Diskusiju neturpināšu kamēr neredzēšu kaut vienu produkcijas projektu ar lockiem. Vai vispār kaut vienu produkcijas projektu. Vēlams ar vismaz vienu lietotāju, kas neesi tu.
-
Pēc felony komentāra var 100% droši spriest, ka viņam nekad nav bijusi saskare ar šādu sistēmu izstrādi. Davai, fellony, interneta veikala linku uz reālu tavu "gudro" temperatūras sensoru (ar cenu).
Piemērs - Massive multiplayer realtime spēle, kur katrs spēlētājs var izmainīt pasaules stāvokli + paralēli pasaules stāvoklis jāmodelē neatkarīgi no spēlētājiem. Bet nav brīnums, ka tu ar tādiem gadījumiem neesi sastapies, jo ņemies ar kaut kādiem vizītkaršu līmeņa projektiņiem.
Galīgi nojūdzies esi? Tu gribi teikt, ka autonomi sensori (aļa advanced metering infrastructure) un sensoru tīkli neeksistē? :D Interesanti, kā tad implementētas gāzes un ūdens apgādes autonomās sistēmas un citi sensoru tīkli (aļa smart grid), un kam tad diez eksistē tādi protokoli kā OSGP, M-Bus utt. utjp. Atkal tu lien ar savu gudrību tur, kur tev nav nekādas sajēgas.
Cenas un veikalus tev meklēt netaisos, ir man labākas nodarbes kur laiku tērēt. Bet ja dikti gribi es tev varu nopārdot savu arduino - sākumpunktam, tā teikt. Lai gan raspberijs ar cylon varētu būt elegantāks.
Un tavs piemērs par MMORPG ir no sēžamā izvilkts - patiesībā, ir tieši pretēji: massively scaled realtime sistēmas pat sapņos nerādās nodarboties ar tādām perversijām, tāpēc ka cilvēki, kuriem pieredze ir praktiska nevis no uz wikipēdiju bāzēta saprot, ka arī konkrētās izmaiņas ir elementāri implementējamas kā rolling mutation model - izvairoties no visa tā overheada ko tu tagad centies tur iebāzt. Vari pameklēt kaut vai EVE online arhitekturas blogpostus un papers kā tas notiek realitātē nevis tavā neloģiskajā prātiņā.
Un par to tavu piezīmi par vizītkaršu projektiņiem - tev vispār ir kaut kāda nojausma ar ko es realitātē nodarbojos? Vai arī tu vienkārši gvelz lai dzesētu muti. Cita starpā, mēs jau kuro gadu gaidam kaut vienu tavu produkcijas projektu redzēt. Būtu tā kā laiks atrādīt.
-
^ tu vairāk laika būtu veltījis programēšanai nevis visādu gifu meklēšanai
Es programmēju 9-12 stundas dienā. Es domāju, pietiks...
-
F3llony tieši sensorus ir jālasa.
Iedomājies kas par bardaku būs ja vairāki slave sensori pēkšņi izdomās RS485 tīklā sūtīt datus. Tam ir domāta viena Master ierīce, kas secīgi apvaicā visus sensorus pēc to adresēm. Manā gadījumā vienlaikus nevar runāt divas ierīces. Sensors ir digitalizēts, t.i. tīri fizikāls sensora elements temperatūras devējs, kā rezistīvs PT100 vai kāda cita tipa devējs. Tad ACP, kas šo signālu nociparo un tālāk pa I2C vai SPI tiek sūtīti dati uz kontrolieri, kas šo Bināro kodu pārveido decimālā formātā un apstrādā saprotamā formātā ierakstot noteiktā reģistrā. Visas šīs darbības notiek onlainā. Teiksim sekundē tiek veikti daži simti mērījumi un tad izvilkta vidējā vērtība uz laika vienību. To tālāk pieprasa Master ierīce. Iedomājies, kas notiks ja to visu Slave ierīces sāks nonstopa grūst vados iekšā. Sākumā masteram ir jāpieprasa viena slave adrese, tad tā atbild. Viss ok. Tālāk tiek apvaicāta otra slave adrese utt. Elektronikā tikai šādi tā saziņa notiek.
Principā no elektronikas puses to var organizēt dažādi. Ir daudz gatavi (ne lēti) risinājumi ar Master kontrolieri un IO moduļiem (tie savā starpā sazinās pa specifiskiem protokoliem), kas pa tiešo nolasa analogo signālu un tad nociparo. Tur ir teiksim viena ACP 16bitu ieeja kuru multipleksē uz vairākiem sensoriem. Tā ka arī šeit sensors nu nekādi nevar runāt īpaši jau rezistīvs elements.
Nu ne gluži. Ne velti es pieminēju semplošanu. Tavai arhitektūra nebūs īpaši efektīva, ne pat īsti stabila.
Ar tavu RS485 M/S arhitektūru:
Tev ir master, kas ik X msec pieprasa sleivam statusu un to reģistrē. Sleivs reportē statusu. Tu glabā katru (vai ja nedaudz pieķēpā loģiku - katras izmaiņās) stāvokli. Tu saņem atjauninājumus no sensoriem noteiktos intervālos un vari palaist garām anomālijas kas var notikt šo intervālu starplaikā. Jo vairāk sensoru - jo lielāks starplaiks.
Ar manu ne-RS485/jebkuru inverse multicast:
Tev ir master. Sensors ir gudrs (lasi - slave, digitalizēts un stand-alone, praktiski PnP). Sensors ik pēc X (m)sec ziņo, ka ir dzīvs (ping). Sensors paziņo masteram aktuālo lasījumu brīdī, kad tas mainās salīdzinot ar sākuma stāvokli (0).
Rezultāts: tu vienmēr zini, ka sensors ir dzīvs neapstrādājot liekus datus, un tu saņem info par sensora stāvokļa maiņu lai nepiesātinātu ne tīklu, ne datubāzi ar lieku informāciju.
Abām arhitektūrām ir plusi un mīnusi - pirmā ir relatīvi vienkārša, low level, un darbosies labi vienkāršākajos gadījumos. Otrā ir ievērojami dārgāka un sarežģītāka implementācijā, taču labi skeilojas un ir pamatā diezgan stabila. Ja pievieno inverse broadcast, arī spof noturīga.
Varu saderēt, ka Felonijs nespētu pat korekti uzrakstīt multithread programmu, kura paralēli procesi izmanto, piemēram, Map-u, nerunājot par sarežģītākām datu struktūrām.
Pirmkārt, bezdēt gribēju uz taviem monolītiskajiem, inter-tredu piebāztajiem monstriem. Otrkārt, tu man vispirms parādi kādu kaut cik populāru keisu, kur darbs ar dajebkādām datu struktūrām atmiņā starp vairākiem trediem ārpus datubāzēm un datastorēm ir vajadzīgs, un tad parunāsim.
-
Codez nejēdz kodēt. Tas arī viss.
PHP var forkot cik vien ienāk prātā, un tas starp citu ir nu ļoti vienkārši izdarāms, līdzīgā manierē kā ar Node subprocesiem, līdzīgā manierē kā Java tredi, līdzīgā manierē kā to dara Skalas aktori, tikai ar nelielu sintactic sugar ar mazāku kontroli pār internals.
Also, tava tizlā "sensoru lasīšana" mani nedaudz kaitina. Sensorus nelasa, sensori paziņo. Ja sensors nejēdz ziņot, tad dotais sensors ir stulbs sensors.
Also, sampling.
-
-
Raksti visu Scalā. Kā Tu nesaproti!
:DD
-
Jā, ports 8080. Ok, pačekošu ielejas ieteikumus, cerams, ka izdosies! :)
Standarta HTTP ports ir 80. Ja nav 80, tad pārlūks nezina aiz kura porta sēž tava aplikācija. Tāpēc arī jāraksta. Nomaini portu uz 80. Ja tas aizņemts - tev ir problēma: visdrīzāk darbojas httpd instance. Ja Apache Httpd nelieto, nokauj jamo un izmanto 80 tomcatam.
node.js MySql ORM
in Javascript
Posted · Edited by F3llony
Tavs biome ir lielisks piemērs kur socketus var un pat ļoti vajag lietot - es domāju, ka flash transports jau sen visiem web spēļu deviem bija spēcīgi apnicis. Taču te ir nianse - websocketiem ir overhead kuru reti kāds ieskaita kopējā "maisā", un tas ir pareiza manis minēto edge keisu apstrāde. Tev biomē viens-divi zaudēti freimi no socketa nu noteikti neko nemainīs - nu labi, kādam čalim noraustīsies "blobs", fine, deal with it. Bet iedomājies šādu situāciju:
Līdz stulbumam ģeneralizēts un balstīts uz manu sarkastisko skatu uz dzīvi, bet tagad iedomājies, ja kāds tūnis kaut kādā naidžērijas bankā kaut ko šādu arī uztaisīs kaut kādā kritiskākā sistēmā, nereģistrēs klienta pusē vai pieprasījums ir ack, nepārbaudīs vai dotais pieprasījums nav ack arī pēc tam kad ir kļūda (nav ack), izdarīs kaut kādus pieņēmumus par steitu utt utjp. Šāda problēma var rasties un rodas, jo šeit ne tikai pats pieprasījums, bet arī servera atbilde nav sinhrona. Tradicionāli ir HTTP GET /send/money/100€ un rezultāts ir vai nu 200OK, vai nu 5xx ej mājās (content length mismatch, partial data, utt utjp), vai pūlo statusu kamēr ir OK (jo tas ir obvious thing, kas ir jādara, pat Dilbertam) - savukārt ar websocketiem tas varētu būt ne tik loģiski, it ipaši ja Dilberts testē localhostā, neizmanto toxiproxy/comcast utml tūļus, un vispār ģeneralizē kaut kādus pieņēmumus.
Un tas ir iemesls, kāpēc visus pārējos datus netransportēt - eksistē jau gadiem ilgi pārbaudīts transports, kurš ir sevi pierādījis kā līdz dumjumam stabils - HTTP.
Es personīgi domāju, ka domāt HTTP vs WS ir galīgi greizi, tiem drīzāk vajadzētu vienam otru augmentēt, ne aizstāt - tevis minētajai biomei etc. un citiem līdzīgiem gadījumiem, no prob, ws ir super cool and fine. Bet citiem, savā ziņā "tranzakcionāliem" gadījumiem - pievienot komentāru, bloga postu, aizsūtīt Petjam vēstuli, es domāju HTTP ir pilnīgi okei.
Totally piedzīvots keiss. Solution:
Starprīdi rēķinājām mēs šādi (uz 1,000,000 konekcijām) i * 0.001, kā rezultāts bija:
kas pamatā ļāva atkopties ļoti, ļoti maigi. + vēl frontendā bija skripts, kas intervālus pagarināja gadījumā, ja konekcija neizdodas ar pirmo reizi (vairāk laika vajag lai atkoptos, utt).
Parasti plānotiem offtaimiem šis pats princips tika izmantots lai gracefully nokillotu serveri un tad load balancerim failover šos te pašus delayed konektus izmētātu pa pārējiem serveriem.