- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: HTTP Zugriff

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    20.08.2008
    Beiträge
    41

    HTTP Zugriff

    Anzeige

    Powerstation Test
    Hey !

    Ich programmiere gerade einen atMega128. An dem Controller ist ein GSM-Modem angeschlossen.

    Ich will auf eine Webseite über GPRS zugreifen um dort ein php-Skript zu öffnen.

    Das funktioniert auch alles soweit gut.

    Jetzt will ich aber die Verbindung zum Webserver aufrecht erhalten. Standartmäßig lösen die Webserver nach dem Zugriff die Verbindung.

    Mein Zugriff im Moment sieht folgendermaßen aus:
    //Socket öffen etc, dann folgende Anweisung senden

    GET /jspkurs/web/script/kap1.html HTTP/1.1
    Host: localhost
    // Jetzt 2x "\r\n" senden.


    Ich habe von einem Paramter "connection" gelesen, der dem Webserver sagt, bleib connectet. Wie sieht dazu der Aufruf auf und muß ich auf der Server Seite noch etwas machen ?

    Könnte das so gehen ?
    GET /jspkurs/web/script/kap1.html HTTP/1.1
    Host: localhost
    Connection: keep-alive
    // Jetzt 2x "\r\n" senden.


    Vielleicht weiß ja jemand etwas ....

    Thx
    Buck

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    15.04.2007
    Beiträge
    55
    Hallo

    Möchte auch Daten über GPRS zum Webserver senden, weiss nur noch nicht wie das geht. Hast Du Beipeilecode in Bascom der zeigt wie es gemacht wird?

    Gruss
    Sato

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    20.08.2008
    Beiträge
    41
    Hey !

    Es gibt sehr viele verschiedne Wege den Zugriff zu programmieren. Deine HW die du benutzt spielt dabei eine große Rolle.

    Erkläre doch mal kurz deinen Aufbau.

    Buck

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    50
    Beiträge
    2.253
    Daten zum Webserver senden geht am Einfachsten per
    GET - Parametern, sprich die zu sendenden Daten werden einfach
    in die Kommandozeile geschrieben.
    sähe dann so in etwa aus:
    Code:
    http://meinserver.info/meineseite.php?datensatz1=xyz&datensatz2=abcd
    Das Script kann die dann schon per $_GET verarbeiten.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von vohopri
    Registriert seit
    11.09.2004
    Ort
    südlich der Alpen
    Beiträge
    1.708
    Hallo Buck,

    Connection: keep-alive

    ist korrekt.

    Http ist übrigens gut dokumentiert und die Dokumentation ist relativ einfach mit einer Suchmaschine zu finden. Beispielsweise hier:

    http://www.w3.org/Protocols/HTTP/1.1...1-spec-01.html

    grüsse,
    Hannes

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    20.08.2008
    Beiträge
    41
    hallo hannes !

    ich werde es einfach mal ausprobieren.

    aber gerade diese funktion ist kritisch. am anfang des www wurden die verbindungen grundsätzlioch geschlossen. heute ist das anders. in jedem header vom server steht die connect art. eigentlich ist es der server der über die connection bestimmt. das bedeutet, daß man auf der serverseite auch noch etwas ändern müßste.

    der befehl connect: keep-alive ist zwar vorhanden, aber nicht wirklich umgesetzt worden. das habe ich halt bei meinen recherchen herausbekommen, die ich definitiv gemacht habe.

    mit meinem post wolle ich auf den erfahrungsschatz der nutzer dieses forums zurückgreifen. das ist mein anliegen.

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    50
    Beiträge
    2.253
    ich frag mich wozu es gut sein soll eine connection
    auf ewig zu halten.
    der server wird das auch nicht mitmachen und der provider
    macht u.u. auch noch ne zwangstrennung wie beim dsl nach
    x stunden.
    du hast doch alles ... n gsm modem um die verbindung herzustellen
    und dann per request die get daten rüber schicken.
    ich kenns zwar nur andersrum, sprich der server löst cronjob aus
    und greift auf den lokalen webserver zu um daten zu pollen, ist
    aber da einwahlverbindung, besser sorum.
    Vorteil wär halt auch, du könntest die verbindung nach datenübermittlung
    trennen ... läuft dann nicht so ins geld.
    um was für daten dreht es sich denn überhaupt?
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von vohopri
    Registriert seit
    11.09.2004
    Ort
    südlich der Alpen
    Beiträge
    1.708
    Hallo buck,

    du hast natürlich nicht die Garantie, dass ein Server, den du nicht selbst betreibst, ein keep alive beherrscht. Darum sollte man nichts davon abhängig machen, und nötigenfalls auf connection close Betrieb zurückgehen können.

    Wenns der server beherrscht, kann der Client connection close oder connection keepalive anfordern. In HTTP schaun dann die beiden Varianten folgendermassen aus (http header und socket Ereignisse im Protokoll):

    Code:
    lookup
    connecting
    connect to 74.125.43.99 bw-in-f99.google.com
    write
    GET / HTTP/1.1
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
    Accept-Language: de-at
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
    Host: www.google.at
    Connection: Keep-Alive
    
    read
    HTTP/1.1 200 OK
    Cache-Control: private, max-age=0
    Date: Sat, 06 Jun 2009 12:19:46 GMT
    Expires: -1
    Content-Type: text/html; charset=UTF-8
    Set-Cookie: PREF=ID=adff0003981ad673:TM=1244290786:LM=1244290786:S=-troxoMuBvG5j02J; expires=Mon, 06-Jun-2011 12:19:46 GMT; path=/; domain=.google.at
    Content-Encoding: gzip
    Server: gws
    Content-Length: 3694
    
    ‹
    
    Verbindung bleibt bestehen.
    Client beendet.
    
    disconnect 74.125.43.99 bw-in-f99.google.com
    
    lookup
    connecting
    connect to 74.125.43.147 bw-in-f147.google.com
    write
    GET / HTTP/1.1
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
    Accept-Language: de-at
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
    Host: www.google.at
    Connection: Close
    
    read
    HTTP/1.1 200 OK
    Cache-Control: private, max-age=0
    Date: Sat, 06 Jun 2009 12:24:35 GMT
    Expires: -1
    Content-Type: text/html; charset=UTF-8
    Set-Cookie: PREF=ID=d047bb5ad1568677:TM=1244291075:LM=1244291075:S=iIVLqQ8TszFRQZCI; expires=Mon, 06-Jun-2011 12:24:35 GMT; path=/; domain=.google.at
    Content-Encoding: gzip
    Server: gws
    Content-Length: 3697
    Connection: close
    
    ‹
    disconnect 74.125.43.147 bw-in-f147.google.com
    
    Server hat beendet.
    grüsse,
    Hannes

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von vohopri
    Registriert seit
    11.09.2004
    Ort
    südlich der Alpen
    Beiträge
    1.708
    Hallo vitis,

    von ewig ist ja auch nicht die rede. Natürlich gibts ein timeout von serverseite. In der HTTP Dokumentation siehst du auch, wie das über die Header kommuniziert werden kann. Unter bestimmten Voraussetzungen spart ein keep alive clientseitig und serverseitig ressourcen, dafür ist es auch vorgesehen und das kann man nutzen.

    grüsse,
    Hannes

  10. #10
    Benutzer Stammmitglied
    Registriert seit
    20.08.2008
    Beiträge
    41
    Hey Vitis !

    Es geht bei mir darum viele Datensätze zu versenden. Im Moment öffne ich immer wieder einen Socket und sende die Daten. Das Öffnen des Sockets dauert nur immer einige Sekunden und ist auch nicht unkritisch (Abbrüche).

    Um dieses zu vermeiden würde ich die Verbindung offen halten und die Zugriffe (GET) auf den Server innerhalb einer Verbindung machen.

    Ich habe jetzt eine andere Lösung gefunden. Ein Protokoll in dem ich viele Daten in ein PHP Skript unterbringe.

    Buck

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test