Kirjoittaja Aihe: Keskinäiset kaverit ja php-palvelin  (Luettu 2252 kertaa)

teele

  • Käyttäjä
  • Viestejä: 817
    • Profiili
Keskinäiset kaverit ja php-palvelin
« : 12.02.21 - klo:13.59 »
Tilanteessa voisi kuvitella olevan vaikka 100 php-asiakassivua, jotka voivat valita kukin vaikka 10 muuta sivua kavereikseen. Tietorakenne olisi ehkä php array avaimena jokaisen oma sivu ja arvona omat suosikit valittuna niistä muista 100 sivusta.

Olisiko mahdollista tehdä php-palvelin

Koodia: [Valitse]
<?php 
// set some variables for configation 
$host "127.0.0.1";
$port 25003;
// naver timeout! then set 0
set_time_limit(0);
// Create socket
$socket socket_create(AF_INETSOCK_STREAM0) or die("Could not create socket\n");
// Bind socket to port
$result socket_bind($socket$host$port) or die("Could not bind to socket\n");
// Start listening for connections
$result socket_listen($socket3) or die("Could not set up socket listener\n");
// Accept incoming connections
// spawn another socket to handle communication
$spawn socket_accept($socket) or die("Could not accept incoming connection\n");
// Read client input
$input socket_read($spawn1024) or die("Could not read input\n");
// Clean up input string
$input trim($input);
/////echo "Client Message : ".$input;  // ei tulostella tässä mitään
// käsitellään asiakkaan kaverivalinnat
$output "tieto asiakaalle kaveritilanteesta laskettuna valintojen perusteella";
socket_write($spawn$outputstrlen ($output)) or die("Could not write output\n");
// Close sockets
socket_close($spawn);
socket_close($socket);
?>


tähän tyyliin niin, että se ylläpitäisi edellä kuvattua php arrayta valinnoista ja jokaista asiakassivua vastaisi tavallinen php-sivu, jossa olisi tämän tapaista koodia, viestinä olisi sivulla tehdyt valinnat

Koodia: [Valitse]
<?php 
$host    
"127.0.0.1";
$port    25003;
$message "tällä sivulla tehdyt kaverivalinnat";
echo 
"Message To server :".$message;
// create socket
$socket socket_create(AF_INETSOCK_STREAM0) or die("Could not create socket\n");
// connect to server
$result socket_connect($socket$host$port) or die("Could not connect to server\n"); 
// Send string to server
socket_write($socket$messagestrlen($message)) or die("Could not send data to server\n");
// Get server response
$result socket_read ($socket1024) or die("Could not read server response\n");
echo 
"Reply From Server :".$result;
// Close socket
socket_close($socket);
?>


Php-pavelimelle pyyntö tulisi kai aina localhostista, koska asiakas-php toimii palvelimen kanssa samassa paikassa??

Pitäisikö php-palvelinkoodia yrittää muuttaa niin, että sillä voisi olla useampi socketti auki samaan aikaan, koska eri asiakkaat voivat haluta tehdä valintansa samaan aikaan. ??

Olisiko olemassa joku kätevämpi tapa tällaisen tilanteen ratkaisemiseksi. Tietokantaohjelmaa ei ole käytössä.



_Pete_

  • Käyttäjä
  • Viestejä: 1836
  • Fufufuuffuuu
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #1 : 12.02.21 - klo:22.33 »
Mkä tässä on varsinainen ongelma ?

teele

  • Käyttäjä
  • Viestejä: 817
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #2 : 16.02.21 - klo:13.06 »
Kysymys taisi olla vähän huonosti kirjoitettu.

Kysymys on siitä, miten olisi toimittava tilanteessa, jossa on esimerkiksi 100 asiakasta ja jokaisen asiakkaan näkymä muuttuu sen mukaan, mitä sellainen toinen asiakas tekee, jonka itse on valinnut vaikuttavaksi ja joka on myös valinnut tämän valinnan tekijän vastavuoroisesti vaikuttajaksi. Kukaan muu asiakas ei tiedä, kenet tietty asiakas on valinnut vaikuttavaksi.

Esimerkiksi A on valinnut B:n ja B on valinnut A:n. tällöin A:n toimet vaikuttavat B:n näkymään ja B:n toimet A:n näkymään. A ei tiedä, kenet B on valinnut eikä B tiedä, kenet A on valinnut ohjelman lähtötilanteessa. Kun A haluaa päivittää näkymänsä, sen on tarkistettava B:n tekemät toimet, vaikka ei tiedä, vaikuttavatko B:n toimet näkymään, koska kukaan ei tiedä muiden tekemiä valintoja. Sama koskee B:tä ja kaikkia muitakin asiakkaita.

Yksi ratkaisu olis 100 * 100 taulukko tiedostona, jota jokainen asiakassivu lukisi tarpeen mukaan ja tarkistaisi sieltä omien vaikuttajikseen valitsemiensa muiden asiakkaiden toimet.

Mutta tällaisessa tilanteessa tulee aika paljon tiedostoluka, kun joka kerralla joka asiakas lukee kaikkien muiden toimintatiedot. Toiveena on, että olisi mahdollista laittaa 100 * 100 taulukko yhteen ohjelmaan ja kaikki asiakkaat keskustelisivat tämän ohjelman kanssa. Kenenkään asikkaan ei tarvitsisi lukea muiden tietoja, vaan ne olisivat tässä taustaohjelmassa.

Kysymyksessä ollut php-palvelin on sellainen esimerkki, mikä tuli vastaan netistä hakemalla, mutta voivatko nettiavaruudessa olevat asiakkaat toimia kysymällä tietoa tältä php-palvelimelta, jos se haluaa asioida localhostin kanssa.

Tämä on täysin uusi alue itselleni ja toivon, että en olisi ymmärtänyt joitain tärkeitä perusasioita väärin, mikä sekään ei ole kovin harvinaista  :)
« Viimeksi muokattu: 16.02.21 - klo:13.22 kirjoittanut teele »

_Pete_

  • Käyttäjä
  • Viestejä: 1836
  • Fufufuuffuuu
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #3 : 16.02.21 - klo:14.46 »
Onko näkymä tässä siis www-sivu jonka php näyttää?

esim näin:

A -> www-sivu <- B


Tässä siis on yksi ja sama näkymä www-sivu joita sekä A ja B voi käyttää ja jos sivussa on toimintoja jotka muuttaa sen sisältöä
niin kummatkin A ja B näkee muutokset?


Ganymedes

  • Käyttäjä
  • Viestejä: 3915
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #4 : 16.02.21 - klo:19.35 »
En tiedä asiasta koodin tasolla, mutta jotenkin tuntuu että tässä mahdollisesti oiotaan miettimättä tietomallia. Itse miettisin tätä objektitasolla ja sitä mitä oikeasti tapahtuu. Oheisena esimerkki objektimalliajattelusta ja käyttäen yhtä yhteistä tietoa käyttäjille.

Mitkä ovat objektiluokat asiassa? Tässä esimerkissä ihminen ja kuntosali. Näiden miettiminen on aivan oleellista.

Mitkä ovat objektiluokan interfacet ja niihin kuuluvat attribuutit? Jälkimmäinen on aika selkeä, mutta interfacet eivät. Tässä esimerkissä on ihmisellä kaksi interfacea: nimitiedot ja kuntosalin jäsenyys. Kuntosalissa on kolme interfacea: nimi/identifikaatio, osoitetiedot, jäsen.

Ihmisen jäsenyyden ja kuntosalin jäsen interfacien välillä on relaatio (relationship). Ei siis itse objektien vaan näiden interfacejen. Tämän avulla nämä kaksi asiaa linkkaantuvat. (Koska relationship on interfacellä, niin hetkeksi kuvitellulla kolmannella objektilla, joka voisi olla vaikkapa yritys, on myös automaattisesti sama relationship jos sillä on sama interface eli automaattisesti myös yritys olisi kuntosalin jäsen).

Nyt sinun tapauksessasi on metodi, jolla jäsenyys tehdään. Käyttäjä A ja käyttäjä B voivat siis näin tehdä, koska käyttävät järjestelmää ihmisinä.

Nyt mennään sitten toiminnallisuuteesi:
Käyttäjällä A voi myös olla metodi, että kun kuntosali linkataan, niin hänen ruudulleen, jäsenyys interfacen attribuutti, jäsenten lukumäärä päivittyy. Tämä metodi käynnistetään muulloinkin, jolloin tämä tieto pysyy ajantasalla käyttäjän A ruudulla.

Vastaava tapahtuu käyttäjälle B, joka saa lukumäärän 2, jos heillä on sama kuntosali.

Eli siis tässä oli esimerkki miten toisen käyttäjän syöte vaikuttaa siihen mitä näkyy toisella, ilman että he suoranaisesti vaikuttavat toisen käyttäjän tekemisiin tai tietävät toisistaan

Seuraava toiminnallisuus:

Käyttäjät A ja B ovat myös superkäyttäjiä, joille on voimassa metodi, päivitä kuntosalin osoite. Näinhän ei voi olla, että molemmat päivittävät eri osoitteen ja päivitys jatkuu hamaan ikuisuuteen, kun kumpikaan ei ole tyytyväinen. Sen lisäksi, pitää olla lukitus, jotta yksi kerrallaan voi tehdä tämän. Tässä siis pitää olla jokin triggeri, joka huomaa edellä mainitun kierteen. Tällöin voi myös olla oma kenttänsä käyttöliittymässä, joka värjäytyy punaiseksi esim. jos: "käyttäjä A on päivittänyt kentän mutta joku muu päivittää sen 24 h:n kuluessa uudestaan" - tai mitä nyt sitten haluatkaan että tapahtuu, jos yhteisen attribuutin päivitys lähestyy järjetöntä. Tässä mielessä yhteisten tietojen päivitys, tietämättä tarkalleen kuka on mukana ja mitä tekee, on aika ongelmallista yleisessä tapauksessa - sinun pitää miettiä jokainen erityinen tapaus erikseen.

Jokaisen attribuutin arvon muutos, siis pitää erikseen miettiä, että mikä on sen suhde, relationship, datamallissa ja mitä metodeja objektiin kuuluu ja milloin näitä metodeja laukaistaan tai miten niitä käytetään.

Yhtenä mössönä näitä kaikkia eri asioita ei voi miettiä - ei ainakaan 100:n käyttäjän järjestelmässä jossa on paljon attribuutteja.

En tiedä onko tästä apua, mutta objektimalli on sikäli mukava, että se kuvastaa todellisuutta melko hyvin. Hierarkinen malli ei kuvasta todellisuutta, mutta kuvastaa toki valittua järjestelmää, joka on ihan hyvä jos mitään muuta ei ole tarpeen valita esim. myöhemmin. Objektimallien kuvaamiseen löytyy toki työkaluja ja implementointiin ohjelmointikieliä. Edellinen kuvaus koski Microsoftin käyttämää objektimallia. Joku muu kertokoon parhaat, avoimet vastineet .ux -maailmassa.

Voihan tuon ylläolevan toki toteuttaa ihan funktionaalisella ohjelmoinnillakin - mitä luultavasti ajat takaa. Vastaavat asiat pitää miettiä siinäkin.
« Viimeksi muokattu: 16.02.21 - klo:19.39 kirjoittanut Ganymedes »

teele

  • Käyttäjä
  • Viestejä: 817
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #5 : 16.02.21 - klo:19.58 »
A voi valita haluavansa yhteistyötä B:n kanssa, ja jos B on valinnut haluavansa yhteistyötä A:n kanssa, kummallekin välittyy tieto yheteistoimintamahdollisuudesta. Tämä olisi varmaan kaikkein yksinkertaisin tapaus.

Etukaäteen kukaan ei tiedä, kuka muu voisi haluta yhteistyöhön, ja päättää jollain arvauksella, kenelle yhteistyötä kannattaa ehdottaa. Ehdotuksia voi tehdä kerralla jonkun pienen rajatun määrän ja ehdotuksiaan voi muuttaa ja poistaa.

Kun A haluaa päivittää sivunsa, se tarvitsee tiedon, onko esimerkiksi B tai C valinnut A:n. Eli päivitystä varten asiakas tarvitsee tiedon omien valintakohteidensa tekemistä valinnoista.

Näkymä on kullakin asiakkaalla oma, josta näkyy kulloisenkin valinnan tuottama tulos eli ne muut asiakkaat, jotka ovat valinneet kyseisen asiakkaan ja jotka asiakas on itse valinnut vastavuoroisesti. Näkymästä voi myös muuttaa omiav alintojaan, jolloin voi löytää uusia yhteistoimintakumppaneita.

Menisi varmaan kätevästi php-taulukolla, joka toimisi yhdessä ohjelmassa, jos kaikkien asiakkaiden omilla php-sivuillaan tekemät valinnat saataisiin välitettyä taulukkoon ja jos taas kaikki asiakkaat saisivat omille php-sivuilleen taulukon tulokset.

Objektimallina:
Ollaan vakoilijoiden maailmassa, jossa on lauma vakoilijoita, jotka seuraavat muiden vakoilijoiden toimintaa. Kukin vakoilija voi seurata pientä määrää muita. Jos vakoilija huomaa seuratessaan jonkun kohteensa seuraavakin itseään tapahtuu jotain, esimerkiksi tieto tästä tilanteesta välittyy kummankin vakoilijan nappikuulokkeessen.

Nettimaailmassa jokaisella vakoilijalla on oma nettisivu, joka ilmoittaa saman asian eli, jos joku toinen vakoilija on valinnut kyseisen vakoilijan nettisivun tarkkailtavaksi. Vakoilijoita on 100 kappaletta ja kaikki toimivat samalla palvelimella  :)
« Viimeksi muokattu: 16.02.21 - klo:20.26 kirjoittanut teele »

_Pete_

  • Käyttäjä
  • Viestejä: 1836
  • Fufufuuffuuu
    • Profiili
Vs: Keskinäiset kaverit ja php-palvelin
« Vastaus #6 : 16.02.21 - klo:22.20 »
Eli on yksinkertaisesti siitä että on olemassa kohde johon käyttäjät A....n voivat "kiinnittyä" tai "irrottautua". Tämän tilan tarvii pitää kirjaa siitä mitkä käyttäjistä ovat näin tehneet ja sen mukaan toimia tuon muodostaman tilan tavalla silloin kuin joku A...n:stä katsoo kohdetta.

Lisäksi voisi myös asettaa tilalle omistajan joka voi yksinkertaisessa tapauksessa olla joku A...n:stä. Siten voisi sisäisessä tilassa olla enemmämn logiikkaa sen mukaan kun tehdään operaatio katso_tilaa(käyttäjänä A....n). Tällöin voisi katsottaessa tapahtua jotain tiettyä jos vaikka tilan omistaa
A, sitä on alkanu seuraamaan B ja C ja sitten tilaa "katsoo (lataa verkko sivun A)" C.

Tähän(kin) pääset php:lla helpoiten käyttämällä tietokantaa kohteiden/sivujen tilan talletukseen.