Hallo, ich möchte Daten über das Internet auf einen (Web)Server uploaden, und zwar soll die Datei (die es noch nicht gibt) direkt auf dem Server erzeugt und die Daten dort eingetragen werden. Geht das in C / C++ über ftp oder mit http ? Hat jemand ev. Codefragmente als Beispiel ?
ftp wirst du nicht verwenden können. Das sagt dir schon der Name "File TRANSFER Protocol". Die einzige Möglichkeit die mir einfällt um auf dem Server Dateien zu erzeugen und zu beschreiben wäre es diesen als Netzlaufwerk einzbinden und dann wie auf einem ganz normalen laufwerk zu arbeiten. Hierfür muss der Webserver aber CIFS/SMB unterstützen damit du ihn als Netzlaufwerk hinzufügen kannst.
Warum sollte FTP nicht gehen? Ist doch genau die Lösung.
Weil er die Datei AUF DEM Server erzeugen möchte und nicht bei sich lokal und dann per ftp hochladen. Eine andere Möglichkeit wäre ein Skript auf dem Webserver (ob nun php, Python, Perl, etc. ist dabei egal). Über diese kannst du dann Dateien auf derm Server erzeugen und beschreiben. Ich mache das in einem php-Skript um bsw. eine XML Datei für eine Fotogallerie zu erzeugen.
@Albert: Nur weil ein normaler ftp-Client eine lokale Datei benutzt muss er das nicht so machen.
asdfg schrieb: > @Albert: > Nur weil ein normaler ftp-Client eine lokale Datei benutzt muss er das > nicht so machen. Wie soll er auf dem Server per ftp eine Datei erzeugen und diese hineinschreiben wenn diese funktionalität vom ftp-Protokoll gar nicht unterstützt wird? Verzeichnisse erzeugen geht, Dateien erzeugen aber nicht.
Albert ... schrieb: > asdfg schrieb: >> @Albert: >> Nur weil ein normaler ftp-Client eine lokale Datei benutzt muss er das >> nicht so machen. > Wie soll er auf dem Server per ftp eine Datei erzeugen und diese > hineinschreiben wenn diese funktionalität vom ftp-Protokoll gar nicht > unterstützt wird? Schau dir doch bitte mal das FTP Protokoll an und nicht nur das, was dir deine FTP-Bibliothek an Funktionalität zur Verfügung stellt. Oder wie denkst du, wie ein FTP Client eine Datei überträgt? * er sendet das Commando: Jetzt kommt ein File und so soll das heißen * danach schickt er die Daten rüber Genau dasselbe kann man locker auch in einem Programm machen: Erst File öffnen, dann Daten nachschieben. Der FTP-Server wird brav bei sich das enbtsprechende File erzeugen und die gesendeten Daten da reinschreiben. Der FTP Server weiß doch nicht, wo die Daten herkommen. Ob die Daten beim CLient bereits in einem File waren oder online erzeugt wurden, ist dem aber sowas von egal. Der nimmt alles was über die Verbdinung reinkommt und speichert es in einer Datei, deren Namen er vorher erfahren hat.
Der Client ist ein Mikrocontroller, der zur Übertragung von Messdaten über ein GSM-Modul per GPRS (mit integrietrem TCPIP-Stack) mit dem Server verbunden werden soll. Gesteuert werden soll soll das ganze mit AT-Kommandos (das GSM-Modul unterstützt nach dem ersten Überfliegen des Datenblattes ftp und http) Das eigentliche Programm auf dem Mikrocontroller wird in C geschrieben. Zur Zeit teste ich die Ansteuerung des GSM-Modules der Einfachheit halber noch über die Ansteuerung mittels UART-Verbindung von einem PC, auf dem ein normales C-Programm läuft.
Albert ... schrieb: > Wie soll er auf dem Server per ftp eine Datei erzeugen und diese > hineinschreiben wenn diese funktionalität vom ftp-Protokoll gar nicht > unterstützt wird? > Verzeichnisse erzeugen geht, Dateien erzeugen aber nicht. Es wäre ganz schön, wenn man auch weiß, wovon man schreibt. Hier mal ein Auszug aus dem RFC 959: 4.1.3. FTP SERVICE COMMANDS [...] STORE (STOR) This command causes the server-DTP to accept the data transferred via the data connection and to store the data as a file at the server site. If the file specified in the pathname exists at the server site, then its contents shall be replaced by the data being transferred. A new file is created at the server site if the file specified in the pathname does not already exist.
Karl Heinz Buchegger schrieb: > Schau dir doch bitte mal das FTP Protokoll an! > > Oder wie denkst du, wie ein FTP Client eine Datei überträgt? > > * er sendet das Commando: Jetzt kommt ein File und so soll das heißen > * danach schickt er die Daten rüber > > Genau dasselbe kann man locker auch in einem Programm machen: Erst File > öffnen, dann Daten nachschieben. Der FTP-Server wird brav bei sich das > enbtsprechende File erzeugen und die gesendeten Daten da reinschreiben. > Der FTP Server weiß doch nicht, wo die Daten herkommen. Ob die Daten > beim CLient bereits in einem File waren oder online erzeugt wurden, ist > dem aber sowas von egal. Ich habe nochmal nachgelesen und muss dir nun recht geben. Ich wusste nicht das der Name der zu übertragenen Datei als Parameter beim STOR Befehl mit übergeben wird sondern dachte der Server nimmt die Daten an und legt sie einfach ab ohne sich darum zu kümmern was es eigentlich ist.
Ah, danke, das mit dem STOR-Befehl ist schon ein guter Hinweis. Und würde das Schreiben von Daten in eine Datei auf dem Server auch mit http gehen ?
Anfänger schrieb: > Ah, danke, das mit dem STOR-Befehl ist schon ein guter Hinweis. > Und würde das Schreiben von Daten in eine Datei auf dem Server auch mit > http gehen ? Laut HTTP Standard: JA, mit dem PUT Befehl. In der Realität: NEIN, weil dieser Befehl von keinem HTTP Server unterstützt wird. gruß cyblord
cyblord ---- schrieb: > Laut HTTP Standard: JA, mit dem PUT Befehl. > > In der Realität: NEIN, weil dieser Befehl von keinem HTTP Server > unterstützt wird. Ironisch oder ernst gemeint? Lässt sich das ev. individuell einstellen, wenn man bei einem Provider Webspace kauft ? Welcher Provider wäre für solche Anwendungen ev. geeignet (die Dateien brauchen nicht so viel Platz, auf jeden Fall weniger als 1 GB)
warum macht du es nicht einfach über eine kleines PHP-Script. Den schickt du die daten per HTTP und er schreibt es auf die Festplatte? Ist das zu einfach?
Peter II schrieb: > warum macht du es nicht einfach über eine kleines PHP-Script. Den > schickt du die daten per HTTP und er schreibt es auf die Festplatte? Ist > das zu einfach? Mit PHP kenne ich mich nicht aus. Du meinst ein Skript, das auf dem http-Server läuft und auf den Eingang von Daten wartet und die dann in eine Datei auf dem Server schreibt ? Hört sich machbar an.
Anfänger schrieb: > Mit PHP kenne ich mich nicht aus. das kann man ja mit etwas willen ändern. > Du meinst ein Skript, das auf dem http-Server läuft und auf den Eingang > von Daten wartet und die dann in eine Datei auf dem Server schreibt ? > Hört sich machbar an. nein PHP warten nicht, es wird in dem moment aufgerufen wenn du die daten per http dort hinschickt.
Anfänger schrieb: > Der Client ist ein Mikrocontroller, der zur Übertragung von Messdaten > über ein GSM-Modul per GPRS (mit integrietrem TCPIP-Stack) mit dem > Server verbunden werden soll. Wie heikel oder kritisch sind die Daten? Darf auch mal eine Nachricht vergessen gehen? Vielleicht reicht dir für's erste eine Minimal-Lösung mit syslog. Jedes unixoide System hat das mit an Bord, oder es lässt sich einfach nachrüsten. Siehe auch http://de.wikipedia.org/wiki/Syslog Hier im Forum hab ich auch von einem Syslog Client für AVRs gelesen: Beitrag "SYSLOG für Ulrich Radigs Webserver auf AVR-NET-IO"
Helfer schrieb: > Wie heikel oder kritisch sind die Daten? > Darf auch mal eine Nachricht vergessen gehen? Es sollte schon zuverlässig arbeiten. Bei den Daten handelt es sich um Messdaten, die vom Remote-System (Mikrocontroller) über ein GPRS-Modul an den Server geschickt werden sollen. Als Server denke ich an einen Standard-Webserver, ich bin noch auf der Suche nach einem geeigneten Provider. Von dort würde ich die Daten dann in eine Datenbank eingetragen, weiterverarbeitet und ggf. visualisiert. Der kritische Abschnitt ist die Übertragung zwischen Remote-System und Webserver.
Anfänger schrieb: > Es sollte schon zuverlässig arbeiten. Bei den Daten handelt es sich um > Messdaten, die vom Remote-System (Mikrocontroller) über ein GPRS-Modul > an den Server geschickt werden sollen. Als Server denke ich an einen > Standard-Webserver, ich bin noch auf der Suche nach einem geeigneten > Provider. Von dort würde ich die Daten dann in eine Datenbank > eingetragen, weiterverarbeitet und ggf. visualisiert. dann kann PHP die daten ja gleich in den DB eintragen - das bietet eigentlich jeder Provider an.
Anfänger schrieb: > Ah, danke, das mit dem STOR-Befehl ist schon ein guter Hinweis. cyblord ---- schrieb: > Laut HTTP Standard: JA, mit dem PUT Befehl. Mhja, wieso kompliziert wenn's auch einfach geht... ;-) Nimm doch den altbekannten GET request - KISS ist angesagt. Seit Urzeiten können jedem HTTP GET Request Parameter übergeben werden, so in der Art:
1 | GET /irgendwo/meinskript?tu-Schreiben&was=bla&opt1=grunz&bli=12345 HTTP/1.1 |
URL encoding beachten und ein paar andere Feinheiten, siehe http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Helfer schrieb: > Nimm doch den altbekannten GET request - KISS ist angesagt. Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von GET verletzt. Mit PUT kann man es in geschätzt fünf Zeilen Ruby erledigen. sinatrarb.com bietet sich an.
Martin schrieb: > Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von > GET verletzt. kannst du mal etwas mehr du sagen? Wo soll hier etwas verletzt werden?
Martin schrieb: > Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von > GET verletzt. Falsch? Es ist genau so vorgesehen und spezifiziert. Es ist IMHO einfach wenig sinnvoll, einen PUT request zu verwenden, um ein paar Bytes auf dem Server "abzuladen". Das zumindest meine ich möchte der TO tun. > Mit PUT kann man es in geschätzt fünf Zeilen Ruby erledigen. > sinatrarb.com bietet sich an. Der springende Punkt ist IMO, wie einfach es auf dem MC implementiert werden kann. Ein HTTP GET ist trivial, ein POST etwas aufwändiger (du meinst doch POST, nicht PUT?).
Helfer schrieb: > du meinst doch POST, nicht PUT?). nein er meint wirklich PUT - wird meines wissens bei WebDAV genutzt.
Peter II schrieb: > Helfer schrieb: >> du meinst doch POST, nicht PUT?). > nein er meint wirklich PUT - wird meines wissens bei WebDAV genutzt. Und nicht standardmäßig von jedem Webserver unterstützt, wer will schon das jeder Mensch potentiell die Möglichkeit hat Daten hochzuladen? Semantik hin oder her... Dann gibt er halt noch einen Fehler/Erfolgstext zurück und bezeichnet sein script als Zugriffslogger welcher die Requestparameter für eine Spätere Auswertung in einer DB ablegt und schon ist die Semantik wieder da... Ansonsten sind weder GET/POST/PUT unterschiedlich 'kompliziert' bestenfalls die Umsetzung in verschiedenen Frameworks.
@Helfer Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen komische Voodoo-Konfigurationen fahren, Google mußte sogar ein Produkt zurückziehen, IIRC. Meditiere halt mal über "safe" und "idempotent". Vorher mußt du aber die Grundlagen von HTTP verstanden haben. Der RFC hilft dabei ebenso wie die O'Reilly-Bücher zu HTTP und REST.
Martin schrieb: > Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen > komische Voodoo-Konfigurationen fahren, Google mußte sogar ein Produkt > zurückziehen, IIRC. wer heute noch bei den dynamischen web mit immer mehr https irgendetwas cachen will, dem ist eh nicht mehr zu helfen.
Nico Sch. schrieb: > Das merkst du aber schon noch selbst? ja deswegen schreibe ich es ja, cachen macht heute mehr arbeit als sinn.
Peter II schrieb: > ja deswegen schreibe ich es ja, cachen macht heute mehr arbeit als sinn. Dass man damit große Teile des Web 2.0 nicht mehr erfasst, ist schon richtig. Und auch Onlinebanking wird man kaum erwischen. Aber es gibt noch eine Menge statischer Seiten, die durchaus gut gecacht werden können. Die Kritik zielte ja darauf ab, dass genau das durch irgendwelche Programmierer mit "Ich benutze mal ein GET, um eine Datei hochzuladen" ganz schön schwer gemacht wird. Den Nutzen von Caching an sich würd ich aber nicht unbedingt in Frage stellen.
Martin schrieb: > Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen > komische Voodoo-Konfigurationen fahren... Mitnichten. Du hast nicht verstanden, was der TO erreichen möchte, nämlich mehr oder weniger regelmässig Messwerte via Mobilfunk übertragen. Dazu eignet sich ein HTTP GET oder POST request prima. Ein Dateiupload ist Quark. WEBDAV und Caching? Hast du verstanden, worum's geht? > , Google mußte sogar ein Produkt zurückziehen, IIRC. Welches denn? > Meditiere halt mal über "safe" und "idempotent". Vorher mußt du aber die > Grundlagen von HTTP verstanden haben. Der RFC hilft dabei ebenso wie die > O'Reilly-Bücher zu HTTP und REST. Ich denke, dass der TO erstmal einen kleinen Erfolg mit einer lauffähigen Konfiguration erzielen möchte. Richtig sicher wird HTTP mit beidseitiger Authentisierung. Ob man das mit einem einfachen 8 Bit MC vernünftig hinkriegt (beschränkte Rechenleistung, sehr wenig Speicher), sei mal dahin gestellt.
Nico Sch. schrieb: > Die Kritik zielte ja darauf ab, dass genau das durch irgendwelche > Programmierer mit "Ich benutze mal ein GET, um eine Datei hochzuladen" > ganz schön schwer gemacht wird. Den Nutzen von Caching an sich würd ich > aber nicht unbedingt in Frage stellen. get ist aber die einzigste möglichkeit für deep links auf anwendungen. Oder für Favoriten. Und wenn es nur eine google suche ist, da will man auch kein caching.
Post ist ebenso okay wie Put. Von webdav sprach ich nicht. Also hör auf, groß rumzutönen und mir Dinge in den Mund zu legen. Und verzieh dich. Cachen sei heute unwichtig, unfaßbar...
Kurz mal wieder ein Feedback von mir (dem Threadstarter) : Nach den Dokumentationen zum SIM900-Modul sieht es so aus, als ob genügend ftp-Befehle über AT-Kommandos unterstützt werden, um Daten in Dateien auf einen Server hochzuladen. Auch eine http-Verbindung scheint mittels der über AT-Kommandos unterstützten http-Fiunktionen möglich. Wie schon gesagt hat das SIM900 einen integrierten TCPIP-Stack. Als MC wird ein MSP430F249 zum Einsatz kommen, das ganze soll eine Anwendung mit möglichst geringem Energieverbrauch werden. Leider hatte ich heute zu wenig Zeit, um weiter zu programmieren, aber in den nächsten Tagen sollte es Fortschritte geben, werde weiter darüber berichten.
Wie ich sehe, hat sich der Thread so ein bisschen an HTTP festgebissen, kann das sein? Aber was dann wieder alles implementiert werden muss.. Denn dann muss auch der "Client" (der Mikrocontroller) das HTT-Protokoll beigebracht werden. Dabei will der TE doch eigentlich nur folgendes: µC verbindet sich mittels TCP/IP zu dem "Server" über einen spezifizierten Port. "Server" akzeptiert verbindung µC sendet daten "Server" speichert daten als Datei. Das kann HTTP und ein gängiger HTTPd (z.B. Apache) natürlich auch ganz wunderbar. Doch ein HTTPd kann noch mehr. Viel mehr. Was folgt ist ein sehr umfangreiches Protokoll. Anstatt nun also auf einem sehr umfangreichen und komplexen Protokoll aufzubauen, könnte der TE, der kein PHP kann dafür aber anscheinend C, sich einen Daemon programmieren und diesen auf seinem Webserver laufen lassen. Der Daemon lauscht dann auf einem Port, über dem sich der µC verbinden kann und dem Server die Daten schicken kann. Das spart eindeutig Code im µC ! µC -> connect to daemon using specified port daemon -> accepts connection µC -> sends login verification data daemon -> checking login data and (if they are valid) sending "OK" message µC -> sending data as plain text µC -> after data has been sent, finishing with \r\n\0.\0 daemon -> stores data as plaintext-file Das ist ein ziemlich einfaches Protokoll (was im übrigen fast jeder hier tag-täglich nutzt). Es lässt sich sehr einfach programmieren und auch der Code-Umfang im µC wird dadurch WESENTLICH gekürzt, als wenn man HTTP implementiert. Das einzige, was dann noch wirklich arbeitet bedeutet, ist die Login-Verfikiation am Daemon zu entwickeln. Und da gibt es schier unendlich Möglichkeiten, wo man die Login Daten unterbringt. Sei es SQL, LDAP, Plaintext, passwd, ActiveDirectory etc ;)
Fabian schrieb: > Anstatt nun also auf einem sehr umfangreichen und komplexen Protokoll > aufzubauen, könnte der TE, der kein PHP kann dafür aber anscheinend C, > sich einen Daemon programmieren und diesen auf seinem Webserver laufen > lassen. er möchte sich aber einen Server mieten - darunter verstehen viele nunmal nur Webspace mit einem webserver. Dort kann man keinen Deamon ausführen. Klar kann man auch einen VServer oder sogar echten Server mieten aber das ist teurer und man hat sich auch noch im die sicherheit zu kömmern. Als nächsten nachteil kommt dazu das heute nun mal http der standard ist. Das heist das man in firmennetzen keine direkte verbindung aufbauen kann - über http geht es aber. http ist zwar nicht perfekt dafür, es ist aber sehr gebräuchlich und üblich. Auserdem ist es fast kein unterschied im Protokoll zu einem eigenem deamon. Man schreibt einfach noch ein festen http header davor und gut ist.
Mein Konzept ist eigentlich (zumindest für´s erste) den Webserver als Relaisstation zwischen dem Remote-Datenfassungssystem und einem eigenen Rechner (bzw. den Rechnern weiterer Nutzer) zu verwenden, damit die einzelnen Rechner nicht ständig eingeschaltet sein muss. Die vom Remote-Datenerfassungssystem auf dem Server angelegten Dateien bekommen individuelle Namen (z.B. aus Datum, Zeit, ID), so dass auch mehrere bis viele in einem (oder mehreren projektspezifischen) Verzeichnissen angelegt und gesammelt werden können. Und vom Server können sie ja dann von den Nutzer-Rechnern zyklisch (z.B. alle 15 Minuten) abgerufen und die Daten weiterverarbeitet werden.
Das klingt nach Datenbank, kleine Daten-Häppchen mit wenig Aufwand per µC ins WEB schieben und erst dort aufwändig visualisieren.
Peter II schrieb: > Man schreibt einfach noch ein festen http header davor > und gut ist. Das ist aber dann auch wieder sinnloses rumgebastel. Denn dann wird die verarbeitung absolut statisch, was ja eben nicht der sinn von HTTP ist. Es ist ja eben so umfangreich, damit es nicht so statisch ist. Und wenn es um einen gemieteten Webserver geht, reicht es nicht, nur den Status Code 200 zu unterstützen. Da brauch man schon mehr. Und dadurch wird der Code auf dem µC unnötig hochgejubelt. Der Aufwand, einen eigenen Daemon mit eigenem Simple Data Transfer Protocol zu realisieren, ist ausserdem wesentlich geringer, als nem µC nun beizubringen, mittels HTTP reine Textdaten mittels POST zu übermitteln.
Fabian schrieb: > Das ist aber dann auch wieder sinnloses rumgebastel. > Denn dann wird die verarbeitung absolut statisch, was ja eben nicht der > sinn von HTTP ist. Es ist ja eben so umfangreich, damit es nicht so > statisch ist. was soll daran schwer sein? send("GET /data.php?data="); //sende daten send("Hallo"); send(" HTTP/1.1\r\n"); send("Host: www.meinedomain.de\r\n"); send("\r\n"); //optional lese errorcode Fabian schrieb: > Und wenn es um einen gemieteten Webserver geht, reicht es nicht, nur den > Status Code 200 zu unterstützen. Da brauch man schon mehr. warum nicht? Etwas wegen Redirekts, wo sollen die denn plötzlich herkommen?
Peter II schrieb: > was soll daran schwer sein? SCHWER ist es nicht, aber einfach unnötig. WARUM soll er ein Protokoll schlecht implementieren, wenn er mit dem SELBEN Aufwand eine saubere Lösung bekommt? Peter II schrieb: > //optional lese errorcode Und schon haben wir den Code wieder aufgeblasen. Peter II schrieb: > warum nicht? Etwas wegen Redirekts, wo sollen die denn plötzlich > herkommen? Ähm, z.B. wenn der Webhoster temporär auf einen anderen Server umschaltet wegen Wartung oder technischem Defekt und bis zum DNS Release mittels 307 weiterleitet. Oder wenn sich das php script im namen geändert hat. Oder wenn Modrewrite benutzt wird Oder oder oder oder.. Und dann wären da auch noch nicht-redirects: 401 - wenn sich die Logindaten geändert haben 403 - kommt auch öfters mal vor, wenn der Server defekt war und ein Backup eingespielt wird, der Vorgang jedoch noch nicht abgeschlossen ist 503 - Wenn die Server überlastet sind 507 - Gerade wenn es darum geht, dass Daten übertragen und als Datei gespeichert werden, MUSS das implementiert sein, damit es ein sauberes Produkt ist. Und ganz wichtig auch ist der Status Code 418 ;) Ihr benutzt doch auch keinen 16t LKW um PIZZEN auszuliefern. HTTP ist einfach too much. Der HTTPd erwartet auch urlencodierte strings. Das heisst, sämtliche Sonderzeichen müssen umgewandelt werden von einem 1 Byte string in einen 2-4 Byte string. Ein µC hat nun mal sehr begrenzten Speicherraum. Und das Programm wird garantiert aus mehr als nur dem Übertragen der Daten bestehen, denn irgendwoher müssen die Daten ja kommen. FTP ist auch nicht das richtige Mittel, da er den Dateinamen garantiert nicht von den "Clients" erzeugen lassen möchte. Wundert mich, dass noch keiner SMTP vorgeschlagen hat ;) Ist doch auch ein Protokoll, um Textdaten über das Internet zu versenden und als Datei auf dem Server zu speichern. Genau wie HTTP und FTP.
Warum kein ssh oder scp ? scp bla user@bar.de:blubb oder ssh user@kiste.net "cat > /tmp/blaber" < /tmp/uu Oder soll (mal wieder) das Rad neu erfunden werden ?
IP schrieb: > Warum kein ssh oder scp ? Dann zeig doch mal dein scp Implementierung für den ATMega8 IP schrieb: > Oder soll (mal wieder) das Rad neu erfunden werden ? Oder wurde (mal wieder) maximal der Threadtitel gelesen? Fabian schrieb: > HTTP ist einfach too much Also man sollte das nicht so verbissen sehen. HTTP gab es auch schon vor Quadcore mit 4Ghz und 20GB RAM... Man muss für einen Client nun wirklich nicht jede Besonderheit des HTTP implementieren besonders wenn der Server bekannt ist und man keine generische Lösung benötigt. Bei was "eigenem" hat man nur wieder das Problem, das sowohl Client als auch Server prinzipiell als Fehlerquelle dastehen, man das wodrüber sich hunderte Leute den Kopf zerbrochen haben nochmal neu erfindet, und bei Problemen man nicht mal auf erprobte Lösungen für das debugging zurückgreifen kann. Fabian schrieb: > Oder wenn Modrewrite benutzt wird Gerade von mod_rewrite kriegt der Client so garnix mit. Auch deine anderen Beispiele sind schon sehr speziell und sicher nix was jeden Tag erwarten muss. Ein simpler Client könnte den Request auch einfach solange wiederholen bis der Server OK liefert, kann dem doch egal sein wieso genau. Fabian schrieb: > Der HTTPd erwartet auch urlencodierte > strings Was hindert einem gleich die Daten als HEXString zu übertragen? Problem gelöst und auch auf einem kleinen uC kein Hexenwerk.
Fabian schrieb: > SCHWER ist es nicht, aber einfach unnötig. WARUM soll er ein Protokoll > schlecht implementieren, wenn er mit dem SELBEN Aufwand eine saubere > Lösung bekommt? weil man auf einem billigen webspace server nichts anders machen kann. Fabian schrieb: > Ähm, z.B. wenn der Webhoster temporär auf einen anderen Server > umschaltet wegen Wartung oder technischem Defekt und bis zum DNS Release > mittels 307 weiterleitet. ich kenne keine hoster wo das jemals vorgekommen ist. Sie haben cluster die von aussen immer über die gleiche IP erreichbar sind. Da macht niemand etwas mit 307. > Oder wenn sich das php script im namen geändert hat. sie genauso wahrscheinlich wie das sich bei einen eigenen protokoll plötzlich der Port ändert. > 401 - wenn sich die Logindaten geändert haben kommt genauso oft vor wie bei einen eingen Protokoll mit login > 403 - kommt auch öfters mal vor, wenn der Server defekt war und ein > Backup eingespielt wird, der Vorgang jedoch noch nicht abgeschlossen ist > 503 - Wenn die Server überlastet sind egal, der atmel kann die daten eh nicht zwischen speicher, sind halt weg. Auch wenn das internet mal 3Tage lang nicht geht. > 507 - Gerade wenn es darum geht, dass Daten übertragen und als Datei > gespeichert werden, MUSS das implementiert sein, damit es ein sauberes > Produkt ist. warum? wass soll den der atmel damit anfangen? Er schickt einfach immer nur eine GET anfage, alles was nicht mit 200 bestätigt wird, kann ja noch mal wiederholt werden. Was dnan nicht durhckommt hat halt pech gehabt. Es geht hier nicht um einen Client-PC sondern um einen µC dort hat man nicht die möglichkeit zur not alles in eine Datei zu schreiben und später noch mal zu schicken.
Peter II schrieb: > hat man nicht die möglichkeit zur not alles in > eine Datei zu schreiben und später noch mal zu schicken. SD Karte...
Hallo, wie beim Threadstart schon beschrieben, versuche ich von einem SIM900-GPRS-Modul Daten an einen ftp-Server zu schicken und dort in einer Datei zu speichern. Zum testen nutze ich ein selbst geschriebenes C-Programm, das die AT-Befehle über UART an das SIM900-Modul übermittelt. Zukünftig soll das Modul von einem Mikrocontroller angesteuert werden, aber für die ersten Tests verwende ich einen PC. Im Prinzip scheint alles zu funktionieren, aber die Datendatei taucht auf dem ftp-Server nicht auf. Unabhängig davon funktionieren die auf gleiche Art an den ftp-Server übermittelten Befehle zur Angabe des Benutzernamnes, des Passworts und Befehle zum Wecghseln des Verzeichnisses und auch zum Anlagen eines neuen Verzeichnisses einwandfrei. Leider kann ich nicht auf das betriebssystem des ftp-Servers zugreifen und das dortige logfile ansehen, was die Fehlersuche wohl vereinfachen würde. Vielleicht fehlt auch nur ein einziges Zeichen in einem der beiden ftp-Befehle zum Schreiben des Dateinamens bzw. beim nachfolgenden Text, der in der Datei enthalten sein soll. Ich gehe davon aus, dass der Datenstream mit dem ASCII-Zeichen EOF "Dezimaler Wert 4" beendet wird. Das ASCII-Zeichen dezimal 26 ([CTRL+Z]) signalsiert dem SIM900-Modul das Ende der zu übertragenden Zeichenkette. Nachfolgend poste ich mal denC-Code mit den AT-Befehlen und die jeweilige Antwort des SIM900-Modules. Hat jemand eine Idee, warum die Datei auf dem ftp-Server nicht angelegt wird ? sprintf(AT_cmd, "AT+CIPMUX=1\r"); SIM900 response cleaned : >"AT+CIPMUX=1 OK "< sprintf(AT_cmd, "AT+CIPMODE?\r"); SIM900 response cleaned : >"AT+CIPMODE? +CIPMODE: 0 OK "< sprintf(AT_cmd, "AT+CGATT?\r"); SIM900 response cleaned : >"AT+CGATT? +CGATT: 1 OK "< sprintf(AT_cmd, "AT+CSTT=\"%s\",\"%s\",\"%s\"\r", "internet.eplus.de", "eplus", "gprs"); SIM900 response cleaned : >"AT+CSTT="internet.eplus.de","eplus","gprs" OK "< sprintf(AT_cmd, "AT+CIICR\r"); SIM900 response cleaned : >"AT+CIICR OK "< sprintf(AT_cmd, "AT+CIFSR\r"); SIM900 response cleaned : >"AT+CIFSR 10.196.204.35 "< sprintf(AT_cmd, "AT+CIPSTART=0,\"%s\",\"%s\",%d\r\n", "TCP", "xxx.xxx.xxx.xxx", 21); SIM900 response cleaned : >"AT+CIPSTART=0,"TCP","xxx.xxx.xxx.xxx",21 OK 0, CONNECT OK +RECEIVE,0,27: 220 Microsoft FTP Service "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > sprintf(AT_cmd, "user XXXXX\r\n%c", 26); // SIM900 response cleaned : >"user XXXXX 0, SEND OK +RECEIVE,0,34: 331 Password required for XXXXX. "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "pass YYYYY\r\n%c", 26); SIM900 response cleaned : >"pass YYYYY 0, SEND OK +RECEIVE,0,23: 230-(BLADE:)XXXXX FTP +RECEIVE,0,27: 230 User XXXXX logged in. "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "PASV\r\n%c", 26); SIM900 response cleaned : >"PASV 0, SEND OK +RECEIVE,0,48: 227 Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "< sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP", str_IP, pasv_ftp_port); SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711" OK 1, CONNECT OK "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "cwd SIM900\r\n%c", 26); SIM900 response cleaned : >"cwd SIM900 0, SEND OK +RECEIVE,0,29: 250 CWD command successful. "< sprintf(AT_cmd, "AT+CIPSEND=0\r"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "TYPE A\r\n%c", 26); SIM900 response cleaned : >"TYPE A 0, SEND OK +RECEIVE,0,20: 200 Type set to A. "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "MKD SIMDIR\r\n%c", 26); SIM900 response cleaned : >"MKD SIMDIR 0, SEND OK +RECEIVE,0,33: 257 "SIMDIR" directory created. "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26); SIM900 response cleaned : >"STOR test01.txt 0, SEND OK +RECEIVE,0,54: 125 Data connection already open; Transfer starting. "< sprintf(AT_cmd, "AT+CIPSEND=1\r\n"); SIM900 response cleaned : >"AT+CIPSEND=1 > "< sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26); SIM900 response cleaned : >"hello inhalt01 1, SEND OK "< sprintf(AT_cmd, "AT+CIPSEND=0\r\n"); SIM900 response cleaned : >"AT+CIPSEND=0 > "< sprintf(AT_cmd, "QUIT\r\n%c", 26); SIM900 response cleaned : >"QUIT 0, SEND OK "< sprintf(AT_cmd, "AT+CIPCLOSE=0,0\r"); SIM900 response cleaned : >"AT+CIPCLOSE=0,0 0, CLOSE OK "< sprintf(AT_cmd, "AT+CIPCLOSE=1,0\r"); SIM900 response cleaned : >"AT+CIPCLOSE=1,0 1, CLOSE OK "< sprintf(AT_cmd, "AT+CIPSHUT\r"); SIM900 response cleaned : >"AT+CIPSHUT SHUT OK "<
Oder ganz kurz formuliert : wenn ich mit dem STOR-Befehl den ftp-Server anweise, eine neue Datei anzulegen, wie beende ich dann den nachfolgenden Datenstrom in diese Datei, damit der ftp-Server das Ende erkennt ? Ich dachte, dafür sie EOF (ASCII 4) zuständig ? sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26); SIM900 response cleaned : >"STOR test01.txt 0, SEND OK +RECEIVE,0,54: 125 Data connection already open; Transfer starting. "< sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26); SIM900 response cleaned : >"inhalt01 1, SEND OK "<
debugger schrieb: > Leider kann ich nicht auf das betriebssystem des ftp-Servers zugreifen > und das dortige logfile ansehen, was die Fehlersuche wohl vereinfachen > würde. Hi, ich kann dich zwar bei der Fehlersuche nicht unterstützen, aber zum debuggen ist es immer besser, wenn man an beiden Seiten mitlesen kann. Ich würde dir empfehlen erstmal lokal einen FTP Server aufzusetzen, damit mit du dir die logdateien angucken kannst. FTP server gibt es für linux und windows recht viele, z.B. hier: http://en.wikipedia.org/wiki/List_of_FTP_server_software oder du nutzt eine virtual machine z.B. von hier: http://www.turnkeylinux.org/fileserver Dann würde ich das ganze erstmal rein lokal bei dir auf dem rechner machen.
Verwirrter Anfänger schrieb: > Ich würde dir empfehlen erstmal lokal einen FTP Server aufzusetzen, > damit mit du dir die logdateien angucken kannst. Danke, solche ftp-Serrver kenne ich. Das bringt mir aber nach meiner Einschätzung nur bedingt was, weil die Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen. Ansonsten müste ich ja ein C-Programm schreiben, das über eine ganz andere Methode auf den lokalen ftp-Server zugreift. Und die Kommandozeilenversion von XP hat wieder eine ganz andere ftp-Syntax.
debugger schrieb: > Das bringt mir aber nach meiner Einschätzung nur bedingt was, weil die > Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet > erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen. Du spinnst. Granatenmäßig.
debugger schrieb: > weil die > Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet > erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen. Wenn du deine IP Adresse kennst, kannst du auch über das internet auf deinen lokalen Server zugreifen. Evtl. musst du noch in deiner Firewall einen Port öffnen oder auf deinem Router eine NAT Weiterleitung einrichten, aber ansonsten gibt es aus Protokoll Sicht keinen Unterschied zwischen dem Webserver und deinem lokalen PC.
Verwirrter Anfänger schrieb: > Wenn du deine IP Adresse kennst, kannst du auch über das internet auf > deinen lokalen Server zugreifen. THX, das wäre einen Versuch wert. Dann werde ich doch mal auf einem Laptop einen ftp-Server installieren und testen, ob ich den so erreiche.
Schön, dass von Genies hier immer noch keiner gemerkt geschweige denn dem TS mitgeteilt hat, dass FTP für Datenlogging nun wirklich Blödsinn ist, schlichtweg, weil die Datei jedes Mal überschrieben wird und man es ohne immensen Aufwand nicht schaffen wird, ein einzelnes vollständiges Logfile zu schreiben. Wäre auch zu einfach, HTTP und PHP zu verwenden, wären ja gerade mal geschätzte 20-30 Codezeilen (Client und Server insgesamt). Nein, stattdessen wird ihm irendwelcher unfunktionaler und/oder komplizierter Schwachsinn empfohlen, bishin zu Socketprogrammierung in C auf dem Server, die nicht nur jenen wesentlich teurer macht, sondern auch noch ein Krampf im Arsch ist. Ein Clientprogramm, das ein paar Dinge per GET überträgt, wäre in kürzester Zeit geschrieben (wohl kürzer, als FTP zu implementieren), ein PHP-Zehnzeiler, der das ganze entgegennimmt und in eine Datenbank schreibt, ebenso.
gaast schrieb: > Schön, dass von Genies hier immer noch keiner gemerkt geschweige denn > dem TS mitgeteilt hat, dass FTP für Datenlogging nun wirklich Blödsinn > ist, schlichtweg, weil die Datei jedes Mal überschrieben wird und man es > ohne immensen Aufwand nicht schaffen wird, ein einzelnes vollständiges > Logfile zu schreiben. Schwachsinn in Tüten! FTP erlaubt auch das anhängen von Daten an eine bestehende Datei. (APPE) gaast schrieb: > Ein Clientprogramm, das ein paar Dinge per GET > überträgt, wäre in kürzester Zeit geschrieben (wohl kürzer, als FTP zu > implementieren), ein PHP-Zehnzeiler, der das ganze entgegennimmt und in > eine Datenbank schreibt, ebenso. Er braucht auf seinem µC doch überhaupt kein FTP implementieren, das hat bereits sein GPRS-Modul er muss lediglich Einzelne Strings an diese Modul schicken. Ob die Sache per HTTP nun einfacher wird hängt erst einmal davon ab ob das Modul überhaupt HTTP unterstützt!
Die Messdaten sollen auf dem Server jeweils in einer eigenen Datei mit individuellem Dateinamen abgespeichert werden. Daten an eine bereits bestehende Datei anzuhängen ist also derzeit nocht nötig. auch wenn das mit ftp ebenfalls gehen sollte. Eigentlich sollte die Datenübertragung mit STOR und einem nachfolgenden Datenstream funktionieren. Das Modul unterstützt auch http, das werde ich auch noch testen, aber als Basis will ich zunächst mal die ftp-Version funktionsfähig haben. So, jetzt werde ich dann den ftp-Server installieren. Wegen einer starken Erkältung bin ich auch mental etwas angeschlagen, also bitte ich für ev. intellektuelle Durchhänger um Nachsicht.
Ich würde dir empfehlen denselben FTP-Server zu verwenden wie auf dem Server. Es kann evtl. sein das sich Server in Details unterscheiden. So wie ich das in der Kommunikation oben sehe läuft da wohl ein Server von Microsoft. Windows XP hat auch einen FTP-Server an Board den kannst du über "Software/Zubehör" installieren.
Normalerweise muß man bei FTP für STOR noch angeben wie die Daten übertragen werden sollen siehe: http://www.nsftools.com/tips/RawFTP.htm#STOR macht das dein "modem" alleine?
Die Kommunikation läuft über eine Verbindung im Passive Mode, die vorher mit dem PASV-Befehl erfolgreich eingerichtet wird (ist auch in der Liste oben enthalten). Es sind zwei Verbindungen aufgebaut, über Port 21 werden die normalen Befehle (z.B. STOR test01.txt) und über den vom PASV-Befahl zurückgegebenen Port (in dem Fall 2711) wird der Inhalt der anzulegenden Datei übertragen (inhalt01): ... sprintf(AT_cmd, "PASV\r\n%c", 26); SIM900 response cleaned : >"PASV 0, SEND OK +RECEIVE,0,48: 227 Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "< sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP", str_IP, pasv_ftp_port); SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711" OK 1, CONNECT OK "< ... sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26); SIM900 response cleaned : >"STOR test01.txt 0, SEND OK +RECEIVE,0,54: 125 Data connection already open; Transfer starting. "< ... sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26); SIM900 response cleaned : >"inhalt01 1, SEND OK "<
Okay, das hatte ich überlesen, normalerweise sollte der Transfer durch das schließen der Passiven Verbindung abgeschlossen werden.
wo werden denn die Daten gesendet? Vorbereitet ist ja alles, aber wo sendest Du diese und wann hat Du dem Server mitgeteilt auf welchem Port/IP gesendet wird oder im passiv Mode? http://www.nsftools.com/tips/RawFTP.htm#PASV STOR Syntax: STOR remote-filename Begins transmission of a file to the remote site. Must be preceded by either a PORT command or a PASV command so the server knows where to accept data from.
Joe Redfish schrieb: > wo werden denn die Daten gesendet? Vorbereitet ist ja alles, aber wo > sendest Du diese und wann hat Du dem Server mitgeteilt auf welchem > Port/IP gesendet wird oder im passiv Mode? Es soll in die Datei "test01.txt" der String "inhalt01" geschrieben werden. Über Port 21 wird die ftp-Verbindung aufgebaut, die Authentifizierung (user, Passwort) durchgeführt, dann wird das PASV-Kommando gesendet und mit dem zurückgeliederten Portwert die Passive-ftp-Verbindung eingerichtet. Das klappt alles und wird mit gültigen Rückmeldungen bestätigt. Dann wird über die Verbindung mit Port 21 und STOR der Dateiname ("test01.txt") und über die passive Verbindung der Inhalt ("inhalt01") gesendet. Eigentlich hätte ich geadacht, der Ablauf entspricht der Spezifikation. ... sprintf(AT_cmd, "AT+CIPSTART=0,\"%s\",\"%s\",%d\r\n", "TCP", "xxx.xxx.xxx.xxx", 21); SIM900 response cleaned : >"AT+CIPSTART=0,"TCP","xxx.xxx.xxx.xxx",21 OK 0, CONNECT OK +RECEIVE,0,27: 220 Microsoft FTP Service "< ... sprintf(AT_cmd, "PASV\r\n%c", 26); SIM900 response cleaned : >"PASV 0, SEND OK +RECEIVE,0,48: 227 Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "< sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP", str_IP, pasv_ftp_port); SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711" OK 1, CONNECT OK "< ... sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26); SIM900 response cleaned : >"STOR test01.txt 0, SEND OK +RECEIVE,0,54: 125 Data connection already open; Transfer starting. "< ... sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26); SIM900 response cleaned : >"inhalt01 1, SEND OK "<
anfänger schrieb: > Eigentlich hätte ich geadacht, der Ablauf entspricht der Spezifikation. Du musst die (PASV) Verbindung aber auch wieder beenden sonst weiß die Gegenseite nicht das die Datei "fertig" ist.
Läubi .. schrieb: > anfänger schrieb: >> Eigentlich hätte ich geadacht, der Ablauf entspricht der Spezifikation. > > Du musst die (PASV) Verbindung aber auch wieder beenden sonst weiß die > Gegenseite nicht das die Datei "fertig" ist. aaaaaaaaaaaaahhhhhhhhhhhhhhhh, DANKE Läubi, das war es ! Jetzt funktioniert die Übertragung einwandfrei ! Die passive ftp-Verbindung muss geschlossen werden, BEVOR das allgemeine QUIT-Kommando über die ftp-Verbindung mit Port 21 gesendet wird. Dann wird auch der Empfang des Dateinhaltes vom Server bestätigt: >"AT+CIPCLOSE=1,0 1, CLOSE OK +RECEIVE,0,24: 226 Transfer complete. "< Danach folgt dann der normale Quit-Befehl : >"QUIT 0, SEND OK +RECEIVE,0,7: 221 "< Ich hatte mich beim Ablauf an einem Beispiel orientiert, das ANGEBLICH funktioniert hat, aber diese Reihenfolge so nicht einhält. Da ist die Fehlersuche dann gleich noch schwerer, wenn man nicht weiss, auf was man sich jetzt verlassen kann und auf was nicht. So, jetzt wird das ganze konsolidiert und dann werde ich auch die http-Übertragung mal testen. Also ist dieser Thread wohl noch nicht zu Ende :-) Übrigens : Das SIM900-Modul macht wirklich einen hervorrragenden Eindruck !
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.