Schlagwort-Archive: tomcat

nodemcu and arduino

having such small device, with wifi and many analog and digital i/o ports by hand, is somehow nice. that general purpose input output connectors are known as GPIO….. the loveley mr. wang from hongkong, tower 4, building c had send me that esp8266 v3 (340) board within the second week, directly from china, by airmail.

nodemcu/esp8266
device ports with addresses

that device ( nowerdays called „iot device“ ) can be used as serial bridge, for incomming / outgoing signals. a little more sophisticated is the idea, to send all the data by http with tcp/ip or as udp paket. a lot of traffic can be estimated, beside failure correction , missing paket and other crapy errors, that are common.

pushing a json string that way, triggered, when the value changes, could be more gentle to the chip. the unknown state of the receiver is the pitfall there. using websockets on the nodemcu will work with some message client, like mqtt, is the next climbing. the client subscribes to a master ( tomcat / rabbit mq or pure servlet with extras )  and  delivers the information straight there. the server will handshake the  request with a response, directly to a open port, on the client ip.

should be all, will see, when the code is working as expected. 20 sensors with 50 samples/second could mean 1000 requests per second – commonly. if nodemcu/raspberrypi3 is able to feature all that, is the question for the comming days. the arduino is something one have to learn, how to use  that efficiently is the first step. the next is, to have some java ide, like eclipse ready with java, then tomcat and a dbms or storage engine, like mariadb installed within a virtual machine, with the same debian, that is used for raspberrypi, that is called raspian. then the code delivery or the binaries should work on both enviroments, even if the architecture will differ between amd and arm.

a related story was some years ago, the teensy to get into the mac

cubieboard

ich bin jetzt doch n bisschen fickrig geworden auf son kleines scheißboard. da ich ohne rootserver und ohne linux kaum an der eisenbahnplatte ( cloud ) weiter schrauben kann, begeb ich mich auf der suche im netz zu einem versand in de_DE.

entweder ich bin zu aufgeregt, zu unkondensiert oder warum auch immer, ich übersehe, dass die erste generation nur single-core ist, 1 gb ram hat und die netzwerkkarte nur 10/100 mbit/s schafft.  egal, für 50€ bin ich ja im budget des raspberry, aber mit doppelt so viel ram UND einem s-ata anschluss. das genügt mir als entschädigung. als ich das cubieboard in betrieb nehme.

cubie connected
cubieboard connected with sata hdd

auf der suche nach dokumentation, manuals, handbüchern – überhaupt irgendwelchen nützlichen informationen finde ich dann nach einigem suchen auch ein paar images, sie sich für sd-card eignen. ausserdem noch ein passendes „brenn-programm“ was die images da drauf tut. dabei fällt mir auch das ein oder andere image für den onboard-nand in die hände. ich saug erstmal was ich finde und probiere die verschiedenen ubuntu/debian/android versionen sukzessiv aus. einige booten garnicht, andere sind in zig versionen vorhanden – welche nehmen?

also bleibt mir wohl nichts übrig, als die verschiedenen konfigurationen zu checken. im wesentlichen schaue ich auf den treiber für die grafik einheit, also die gpu. dort ist eine mali-gpu verbaut, die direkt von arm stammt. das passenste triebwerk heißt „sunxi“ und ist direkt vom hersteller. die cpu, also der system-on-a-chip ( soc ) ist von ( ehemals allwinnertech ) nun unter http://cubieboard.org/model/ erreichbar und was dass heißt,mal schauen.. der schafft wohl 1080p, wie da im datenblatt steht – fragt sich nur mit wieviel frames pro sekunde :p

toll, warum hab ich die letzten monate bei den fights der x-server/clients nicht aufgepasst. mir, wayland, mesa, x11 … man was es da nun alles für zeug gibt. und wie zum henker wuppt man den treiber jetzt in den kernel :/ ich glaub, die frage krieg ich so schnell nicht beantwortet, daher krampf ich nicht weiter rum und mach mit config und install weiter.

einige versuche später bin ich noch nicht klüger, ich weiß zwar jetzt welche pakete so halbwegs laufen und wie man mit dem speicher haushaltet, frisch gebootet verbraucht das ding 80 mb mit xfce dann 180. ist der browser offen, sinds so um die 280 gb. tomcat läuft schon im hintergrund, oracles java ist auch drauf, nur die grafik ruckelt wie sau. von dem gigabyte ram sind 808 mb verfügbar, da bleibt noch ein bisschen luft für arbeitsdaten. jedoch noch kein open.gl, kein videostreaming, kein garnix in der richtung. die cpu auf vollanschlag kotzt, doch der treiber ist wohl noch immer nicht im kernel. muss ich mich jetzt wohl direkt mehr mit beschäftigen…..

cubie housed
cubieboard 1 in plexiglas behausung

tolle wurst, auf der einen seite lockt das ding mit kapazitäten, die eigentlich als settop-box ausreichen sollten und mir das video auf den fernseher streamt, auf der anderen seite könnte ich mir ein mini-nas bauen, da die sata-schnittstelle sowie drei usb anschlüsse platz für erweiterung lassen. aber ohne anständigen grafik-treiber, wirds wohl erstmal nix mit dem streaming-client. nuja, als load-balancer sollte der dampf wohl ausreichen, um die 100 mbit/s zu sätigen. übliche einstiegs-firewall-systeme haben auch nicht mehr und dsl oder vdsl ist derzeit auch nicht wesentlich schneller.

anotherWebServer

as i patched lighthttpd to work with the servlet and the next patches discontinued over a period, i was somehow motivated to check another services, for the same reason.

i just needed the webserver to redirect and reverse proxy the requests and responses from the different instances/services to the client. no php, just port handling and some folder/path specialties. so i kicked lighty and droped nginx on the system.

the configuration wasnt that re-usable as i hoped, but the plenty examples on the web made it possible to came up with the service after two weekends. nginx performed well in the official benchmark examples and i was happy with the result, ive seen on my own on the examples i made. handling the j-session-id was done with a patch and the round-robbin worked much more smooth, then before.

the delivered pages were quick and the hunger for ram was low, so i raised the caching on the webserver a bit higher and played with different configurations between tomcat and nginx over the next weekends. i was ok with what ive seen, so the need to dive into the apache config was not a topic anymore.

tomcatServer

as i have the rootServer, i can try and play niceley with my own coded stuff in java, running on tomcat. as the default-webserver just having the php stuff on it, i was looking for my own machine ( or at least for the chance to deploy my stuff ) since a long time.

with no big experience in the hosting field, iam not sure to put the tomcat naked onto the web, so i decide to hide the service behind a proxy/router. after i looked into the given examples, apache could be used therefore. thats to easy, i thought and i remembered some lighthttpd from my school, that one professor took for his page.

configuring the ports and the reverse-proxy was done quite quick, but having more then one subdomain means more then a single config-file. another thing is, that i want to play with load-balancing, so the config was done in three parts.  as example, the workflow of a domain like reporteer.ioioioio.eu

part 1:

reporteer.ioioioio.eu to localhost:80. the gateway with round-robbin load-balancing on a virtual host (server-0) in berlin and redirect to the server-1 in jena.

part 2:

redirect from port 80 on server-0 to server-1 port 80, where another lighty was running.

part 3:

redirect from port 80 to port 8080, where tomcat was running and targeting the servlet-path like http://server1:8080/reporteer/

caching on each layer for different filesizes and different file-types was done that way. as the commong filesize on the http level is mostly below 64 kilobyte ( to measure ) i passed files from the servlet between 64kb and 1mb as java-cache, smaller files on the lighty-instances, separated for images and js/css.  so, some css and some javascript ( lets say up to 8 ) per request was reasonable. a unbounded amount of images where handled by the servlet, beside tiny pictures, like thumbnails and icons.

so i felt a bit save for my tomcat, that exploits or my shity code wont run into a desaster for external incomming requests on port 80.  „the evil hacker“, who wanted to get inside the machine would have to overcome the multiple redirect-layers on the plain/vanilla web-server, to catch the tomcat. beside the fact, that i didnt used any php/cgi nor sql-engine, the chance to fail to quick was not my point anymore.

but the main aspect is, that i can run active code now on the machine. before that, i just made passive / xml based stuff with gwt to run on the vhost i had. now remote-procedure-calls ( rpc ) are possible, beside general httpRequest.