Inlägg

Inlägg som Wixner har skrivit i forumet
Av Wixner

Kommer detta verkligen att påverka prestandan negativt? Möjligtvis om GTX 1070 orkar driva 4K - annars kan jag inte tänka mig att bandbredden i GDDR5 skulle vara en flaskhals för den här modellen

Av Wixner

Jag tackar samtliga i tråden för all hjälp.

Logik och Presentation har separerats, men Logik har även delats in i två: Web och Klient och nu fungerar allting som det ska, oavsett vilken väg du kommer.

Tack för input

Av Wixner
Skrivet av Madsoul:

Licenser? Varför skulle det kosta att köra asp.net?

Med Visual Studio kan du stortsett klicka dig fram en bootratp "frontend" för att läsa och skriva till din databas.

Jag var lite luddig där med (inte bra att skriva forumtrådar när man jobbar) - det jag menar är ju förstås, så vitt jag vet att ASP.NET måste snurra på en windowsplattform, därav en licenskostnad

Av Wixner

@Teknocide:

Japp - Min terminologi är väl inte riktigt 100%-ig, eller inte ens 20%-ig antar jag
Då separeras ju presentationslogik (HTML) från applikationslogik (PHP) och då frångår man ju de "Best Practices" som jag hittat att man inte bör separera dessa...

Av Wixner

Undra om kontrollpanelen fortfarande krashar under Windows 10...

Av Wixner

Nu ska vi se om jag kan göra mig lite bättre förstådd; nedan har ni min nuvarande login.php utan modifikationer:

<!-- TODO + create login-form + create feedback-forms - log all errors to a database and send an administrative email ini_set('display_errors', 'On'); error_reporting(E_ALL); --> <?php include_once './lib/bytewizards/class.Session.php'; $session = new Bytewizards\Session(); session_set_save_handler($session, true); session_start(); if(isset($_SESSION['id'])) { header("Location: /profile.php"); exit(); } ?> <!doctype html> <html class="no-js" lang=""> <head> <meta charset="utf-8"> <meta http-equiv="x-ua-compatible" content="ie=edge"> <title>Bytewizards Account</title> <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="apple-touch-icon" href="apple-touch-icon.png"> <!-- Place favicon.ico in the root directory --> <link rel="stylesheet" href="css/normalize.css"> <link rel="stylesheet" href="css/main.css"> <link rel="stylesheet" href="css/login.css"> <script src="js/vendor/modernizr-2.8.3.min.js"></script> </head> <body> <!--[if lt IE 8]> <p class="browserupgrade">You are using an <strong>outdated</strong> browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p> <![endif]--> <!-- Add your site or application content here --> <?php try { $dsn = 'mysql:host='.'localhost'.';dbname='.'bytewizards.se;charset=utf8'; $options = array( PDO::ATTR_PERSISTENT => true, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION ); $pdo = new PDO($dsn, 'root', '', $options); if(isset($_POST['login'])) { $statement = $pdo->prepare('SELECT id, username, password, verified FROM accounts WHERE username = :username'); $statement->bindParam(':username', $_POST['username']); $statement->execute(); if($statement->rowCount()) { $account = $statement->fetch(PDO::FETCH_ASSOC); if(password_verify($_POST['password'], $account['password'])) { if($account['verified']) { $_SESSION['id'] = $account['id']; header('Location: /profile.php'); exit(); } else { echo "valid username and pasword, but account needs to be validated"; } } else { echo "invalid password (to be ofuscated)"; } } else { echo "invalid username (to be obfuscated)"; } } else { ?> <form action="" id="form" name="form" method="post"> <div id="tab-content2" class="tab-content"> <center> Username<br><input type="email" name="username" id="username" required><br> Password<br><input type="password" name="password" id="password" required><br><br> <input type="submit" value="Login" name="login" id="login-button"> </center> </div> </form> <?php } } catch(PDOException $exception) { echo $exception->getMessage(); } ?> <script src="https://code.jquery.com/jquery-{{JQUERY_VERSION}}.min.js"></script> <script>window.jQuery || document.write('<script src="js/vendor/jquery-{{JQUERY_VERSION}}.min.js"><\/script>');</script> <script src="js/plugins.js"></script> <script src="js/main.js"></script> <script src="js/verify.js"></script> <!-- Google Analytics: change UA-XXXXX-Y to be your site's ID. --> <script> window.ga=function(){ga.q.push(arguments);};ga.q=[];ga.l=+new Date; ga('create','UA-XXXXX-Y','auto');ga('send','pageview'); </script> <script src="https://www.google-analytics.com/analytics.js" async defer></script> </body> </html>

Dold text

och som @Tunnelsork säger så använder Unity HTTP för att kommunicera med ovan angivna fil för att försöka autentisera sig, vilket den också gör om jag anger ett existerade användarnamn och lösenord i _POST (komponeras från WWWForm i Unity). Problemet är att jag får hela sidan, komplett med HTML och processad PHP som svar.

Min tanke är då att bryta ut all PHP-logik till en egen fil (login.php) och byta namn på den fil som bara innehåller html till login.html.
Spelklienten kan nu kommunicera direkt med login.php utan att få HTML-kod i svaret och webläsare kan nå samma funktionalitet, via login.html (som anropar, inkluderar) login.php.

Av Wixner
Skrivet av Teknocide:

Efter att ha läst igenom tråden antar jag att du vill att spelet ska kommunicera med spelservern genom ett webbapi. Det känns otroligt bökigt att använda en PHP-fil för att hantera all serverkommunikation och dessutom serva en webbplats till besökare. Finns det någon särskild anledning till att du vill ha det så?

Egentligen tycker jag att du av säkerhetsskäl bör du separera webbplatsen och webbapiet ännu mer och se dem som två helt separata tjänster, där åtminstone webbapiet kräver autentisering.

Den enda anledningen är egentligen gemensam PHP-kodbas då både websidan och spelklienten (än så länge) har samma funktionalitet (registrera konto, validera konto och logga in / ut)

Av Wixner

@dallan87:

Att köra under ASP kräver (?) licenser, med PHP finns det oändligt med möjligheter att köra gratis

Sidan ska, som jag nämnde i ett tidigare svar, bara agera frontend för att läsa/skriva data till/från ett mysql-galerakluster

Av Wixner
Skrivet av dallan87:

@Wixner:
Läs redigeringen av mitt inlägg

Kan även säga det , att bygga ett spel som nybörjade i php eller html, det är nog inget du ska satsa på.

Lär dig först hur det fungerar, hur man bygger enklare sidor, jag har hållt på med hemsidor i 10 år och har byggt ett x antal spel.

Du kommer använda dig av ofantligt många IF-satser, du kommer använda dig av enormt mkt sql och sessions, kan du inget av det, då bör du titta på lite tutorials om det.

Annars kan du bara pma mig så ska jag hjälpa dig

Det är precis det jag har som ett av lösningsförslagen - spelklienten pratar direkt med PHP-skriptet, och webbläsarna pratar med HTML som inkluderar dessa script, men då "Best Practise" för HTML/PHP verkar vara inbäddning så funderar jag på om det är rätt väg att gå

WEB KLIENT ^ ^ | | HTML <- PHP

Av Wixner
Skrivet av dallan87:

@Wixner:
Läs redigeringen av mitt inlägg

Kan även säga det , att bygga ett spel som nybörjade i php eller html, det är nog inget du ska satsa på.

Lär dig först hur det fungerar, hur man bygger enklare sidor, jag har hållt på med hemsidor i 10 år och har byggt ett x antal spel.

Du kommer använda dig av ofantligt många IF-satser, du kommer använda dig av enormt mkt sql och sessions, kan du inget av det, då bör du titta på lite tutorials om det.

Annars kan du bara pma mig så ska jag hjälpa dig

Skrivet av Alling:

Om du vill kunna anropa serversidekod asynkront kanske AJAX (XMLHttpRequest) är det du söker?

Är det ett onlinespel du utvecklar? Annars kan du ju göra allt i JavaScript.

Jag ber om ursäkt om jag varit lite luddig i vad det är jag utvecklar

Spelet kommer inte vara 'online' i den bemärkelse att man spelar med eller mot varandra i realtid utan spelklienterna kommer bara dela gemensam data (som ligger i en databas som kräver autentisering) och kommer vara utvecklat med Unity3D. Det enda som kommer att förläggas till webben är ett frontend mot databasen.

Jag har erfarenhet av både MSSQL, MySQL, C# och Unity3D så spelutvecklingen i sig kommer inte vara några problem, det är bara webbutveckligen som jag inte har erfarenhet av.

Av Wixner

Jag förstår om det låter lite dimmigt

Allting (registrering, inloggning, sessioner) fungerar utmärkt med inbäddad PHP likt den nedan

<html> <?php echo "phpversion();" ?> </html>

men eftersom att min spelklient ansluter till samma sida (www.minserver.se/login.php) så får jag all HTML samt den processade PHP-koden tillbaka som svar, istället för bara resultatet av PHP-koden.

Så frågeställningen är den likt jag tidigare nämnde: Ska jag separera PHP från HTML och skicka spelklienten direkt på PHP-skriptet och webbläsare mot HTML (som i sin tur inkluderar PHP-skriptet) eller om jag ska fortsätta köra med inbäddad PHP i HTML och skicka med en _POST-variabel från spelklienten som tolkas av PHP-skriptet och inaktiverar HTML

<?php if(isset(_POST['game'])) { // .. bara PHP-output } else { ?> <html> ... </html> <?php } ?>

Av Wixner

HTML och PHP - att separera eller inte separera

Hej,

I dag kör HTML med inbäddad PHP i filer med filändelsen .php och allting fungerar som det ska via de webbläsare jag har testat.
Till saken hör den att mitt spel som jag håller på att utveckla också behöver kunna anropa de inbäddade PHP-skripten men då de ligger inbäddade i HTML så får jag tillbaka hela websidan tillbaka till min klient, vilket inte är helt optimalt.

Som den absoluta nybörjare på webbutveckling jag är så ser jag två lösningar på problemet:
1. Separera HTML och PHP och låta spelklienten ansluta direkt till PHP-skriptet (http://www.minserver.se/login.php) och anropa PHP-skriptet från HTML (http://www.minserver.se/login.html)
2. Skicka med en _POST-variabel från spelklienten och ignorera HTML-output om den är satt

Hoppas ni förstår mitt dilemma och min terminologi...

Av Wixner
Skrivet av Nixus:

//
Angående Xeon-D vs Xeon-E3v5: Xeon-D är riktigt häftig! Många kärnor ihop med hög energieffektivitet. Men enligt min erfarenhet så är det oftast en hög enkeltrådsprestanda som är önskvärd. Ska man in och pilla själv med en ny VM eller göra en hel del konfigurationsändringar i en annan VM så är det en hög IPC och klockfrekvens inklusive turbo-boost som är avgörande för upplevelsen. Med 10-20 VMs på nuvarande server så ligger CPUn mestadels under 10% användning. Slutsaten är att CPUn räcker till. 64 GB RAM bör också räcka i åtminstone tre år.
//

Jag är villig att motsäga mig detta. Väldigt få maskiner som lämpar sig för virtualisering utnyttjar CPU till den grad att högre klockfrekvens och IPC skulle vara avgörande. Jag garanterar (såvida inte du bestämmer dig för att virtualisera en HPC-plattform ) att det är antalet IOPS eller mängden RAM som kommer vara den första flaskhalsen i ditt system.

Av Wixner
Skrivet av Tunnelsork:

Ja, men det är normalt sett inte ett problem. Om klienten har slängt uppgifterna i sin ände så ska inte sessionen användas igen utan bara rensas vid ett senare tillfälle, och de är ofta ganska små. Det brukar räcka att koppla samman klientens session med en användare eller liknande, och sedan hanterar man resten (som t.ex. kundvagnar) separat ($_SESSION bör varken användas som cache eller databas).

Ber användaren om att logga ut så kan du ju som du säger radera det manuellt, men om man av någon anledning måste radera uppgifterna så snart som möjligt så får man försöka arbeta runt det; ett par alternativ kan vara att flytta lagringen till klienten eller att ha väldigt låg timeout och att pinga servern för att indikera aktivitet.

Mina planer är bara att spara användarens id (krypterat) i $_SESSION så användaren kan använda samma session över flera webservrar med gemensamt databaskluster för lastfördelning och failover. All annan information kommer att sparas i databasen.

Verkar som att allting fungerar nu när jag manuellt triggar GC (för funktionstest) vid open.

Av Wixner
Skrivet av Tunnelsork:

Problemet är att servern aldrig får reda på att du stänger webbläsaren; det finns ingen aktiv anslutning mellan de två utan de skickar i princip lappar mellan varandra. Serverns roll är att vänta på en inkommande lapp (en request), att agera på denna och generera ett svar (ett response); den märker inte själv om klienten går och gör något annat, och klienten skickar ingen request för att informera. Sessionsdatan kommer alltså ligga kvar i serverns ände till dess att den fångas av SessionHandlerInterface::gc().

KLIENT | Request | | Request | | EXIT * -------------------∨--------------∧-----------∨------------∧ SERVER | (väntar) | Response | (väntar) | Response | (väntar)

Efter varje svar stänger PHP ner ditt script och anropar alla destruktorer som behövs, och nästa request börjar om från noll. Loggar du ut i sessionshanterarens destruktor så kommer det alltså försökas efter varje request / "sidvisning".

Så att "stänga" sessioner på servern innefattas alltid av GC (eller manuella session_destroy() i samband med timeouts eller utloggningar)

Av Wixner

@noyce:

SessionHandlerInterface överlagrar de funktioner (read, write, gc, open, close, destroy, http://php.net/manual/en/class.sessionhandlerinterface.php( som används av $_SESSION så rent tekniskt fungerar det som vanliga fil- eller minnesbaserade sessioner.

Jag ska testa att använda destruktor-lösningen, men frågan är om det är -rätt- lösning eller om det är -en- lösning.

Av Wixner

[PHP7] Problem (?) med SessionHandlerInterface och $_SESSION

Hej,

Jag har implementerat SessionHandlerInterface likt följande:

<?php class Session implements SessionHandlerInterface { protected $pdo; public function __construct() { $dsn = 'mysql:host=' . 'localhost' . ';dbname=' . 'bytewizards.se'; $options = array( PDO::ATTR_PERSISTENT => true, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION ); try { $this->pdo = new PDO($dsn, '********', '********', $options); } catch(PDOException $exception) { echo $exception->getMessage(); } } public function open($save_path, $session_name) { if($this->pdo) { return true; } else { return false; } } public function close() { $this->pdo = null; return true; } public function read($session_id) { $statement = $this->pdo->prepare('SELECT data FROM sessions WHERE id = :session_id'); $statement->bindParam(':session_id', $session_id); $statement->execute(); return $statement->fetchColumn(); } public function write($session_id, $session_data) { $session_timestamp = time(); $statement = $this->pdo->prepare('REPLACE INTO sessions VALUES(:session_id, :session_timestamp, :session_data)'); $statement->bindParam(':session_id', $session_id); $statement->bindParam(':session_timestamp', $session_timestamp); $statement->bindParam(':session_data', $session_data); return $statement->execute(); } public function destroy($session_id) { $statement = $this->pdo->prepare('DELETE * FROM sessions WHERE id = :session_id'); $statement->bindParam(':session_id', $session_id); return $statement->execute(); } public function gc($maxlifetime) { $session_timestamp_timeout = time() - $maxlifetime; $statement = $this->pdo->prepare('DELETE * FROM sessions WHERE timestamp < :session_timestamp_timeout)'); $statement->bindParam(':session_timestamp', $session_timestamp_timeout); return $statement->execute(); } }

Dold text

och använder den likt följande:

[file1.php] <?php $session = new Session(); session_set_save_handler($session, true); session_start(); $_SESSION["SESSION_DATA"] = 663154; [file2.php] <?php $session = new Session(); session_set_save_handler($session, true); session_start(); echo $_SESSION["SESSION_DATA"]; // 663154

Dold text

och allting som jag har implementerat (open, read, write, gc) fungerar, men sessionen raderas inte på servern när jag stänger webläsaren. Anropar jag 'session_destroy()' manuellt så raderas sessionerna korrekt i databasen. Har jag missuppfattat hur $_SESSION fungerar eller har jag missat något?

Tack på förhand

Av Wixner
Skrivet av danedi:

@Wixner:
Wow?! Betalar folk så mycket för en lur? Själv så är den dyraste telefonen jag någonsin köpt en n-gage qd för 2000kr. (Förutom den så har ingen av mina telefoner kostat över femhunkan)

Skrivet av Stefflo:

En spelkonsoll byter man dessutom ut med ca 5-8 års tid och då har många av de glada telefonanvändarna bytt sin telefon mellan 3-16 gånger och även kanske mer. Vissa tycks ha behov av en ny telefon i kvartalet, minst.
Marknaden för telefoner är så enormt mycket större än hos spelkonsoller och därför blir också utvecklingen lidande och då även valet av komponenter.
Det är också en stor skillnad att lägga upp informationen på en 3-5 tums skärm och en 40-70 tums skärm då alla ska ha den bästa grafiken.

Med tanke på att Apple fortfarande tar (eller tog) 12k för sin senaste iPhone med 128GiB lagring och Samsung/Sony/LG ligger kring 5-6 för sina toppmobiler så är folk villig att betala. Fördelen telefoner har över konsoller är väl abbonemangsformen där du betalar av mobilen samtidigt med ditt telefonabonnemang.

Räkna på samma abbonemang (3-500kr i månaden i tre år) så kan du få en fin spelkonsoll där också...

Av Wixner

Så länge som folk är villig att betala 6-12k för en telefon,men absolut inte mer än 3k för en spelkonsoll är väl jämförelsen inte riktigt rättvis?

Av Wixner
Skrivet av Dr.Mabuse:

Eftersom viruset kommer som bilaga så är det relativt enkelt att ta bort, det är bara att radera mejlet.
Det är inget virus i ordets ursprungliga bemärkelse eftersom det inte sprider sig, den "bara" förstör.

Har hört från två säkra källor att det dessvärre inte hjälper att betala, du får ingen nyckel. Det är återställa backup som gäller.

Ja det skulle inte förvåna mig, det beror ju på ligan eller ligorna som står bakom utsckicken. Vissa är väl mer hederlig än andra

Skickades från m.sweclockers.com