Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
Post Reply
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote:Btw, how's the RAM on the VPS with Tomcat? If it's already at the top, the whole webapp thing is a nogo.
In keeping with the minimalism and fast processors+small ram motif, the server is 3.4ghz with 256 ram so it's all processor and internet connection. There are other VPS that are cheaper with more ram, but I did a lot of investigating and found that internet connection is pretty much impossible to beat. The CPU speed is more than enough and the ram I don't know how much is needed for that web stuff. It has ~165megs free with Apache and chatserver running. The ram cost of the C versions for score,gameplay,file,forum translater, etc(basically all the same program, with different logic handlers) will take maximum of 10 megs put together, except for that minecraft idea of course the sky is the limit.
uze6666 wrote:For sure I would much prefer a web app for the scoreboard.
I'm all for it. I know that stuff is very resource heavy and I don't know how to set it up but try it out and see if it works ok I would say. I don't think UzeNet will be built in a day and I don't think we can have a good system without first having a version of everything running and then revise and optimize from there. I'll continue making C versions just so we have some preliminary version of the final product done, and it will at least make it obvious what is good and what needs changes as a proof of concept. This will be a ton of work before it's done, but if everything was working it would be possible to convert those ideas to any paradigm.

Edit-plus there is no reason any of that non-latency critical stuff has to be on that particular VPS if that seems better. Anything that is reliable should be good, the game networking is the only part that is latency important.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

I'm all for it. I know that stuff is very resource heavy and I don't know how to set it up but try it out and see if it works ok I would say. I don't think UzeNet will be built in a day and I don't think we can have a good system without first having a version of everything running and then revise and optimize from there. I'll continue making C versions just so we have some preliminary version of the final product done, and it will at least make it obvious what is good and what needs changes as a proof of concept. This will be a ton of work before it's done, but if everything was working it would be possible to convert those ideas to any paradigm.
Totally agree. Let validate concepts works in whatever technology fits the bill. C and Java are very close in syntax for procedural code, so worst case it would be very easy to port C to Java. Tomcat is a pretty lightweight for a web app server, I deployed it on the VPS, eats about 70Megs of RAM with the console app. That may seem big, but its minuscule compared to what WebSphere and Weblogic servers takes! The VPS you found has very good prices, in fact its lower than all I found. Worst case I could contribute and we could double the RAM on that server. Although Linux server would be cheaper I must admit a *greatly* prefer working on Windows since I feel at home. :mrgreen:

Btw, I can't recall if I saw it somewhere, did you wire up your Uzebox and esp8266 and connect to the chat server using my demo program?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote:I deployed it on the VPS, eats about 70Megs of RAM with the console app.
Nice work, that isn't too bad at all. If it needs more ram later then I'd say upgrade, but I think it's ok with ~100mb free for current plans.
uze6666 wrote: Although Linux server would be cheaper I must admit a *greatly* prefer working on Windows since I feel at home.
<rant>
I am the exact same and the ridiculous thing is I literally feel "guilty" for using Windows because I absolutely love Linux conceptually, the intellectual mystique, what it stands for, etc. I've tried using it as my primary OS several times over the years, but damn, if the most boring thing in the world to me, is remembering a bunch of cryptic details I don't already know and I wont use often enough to justify learning them.
</rant>
I'd say windows is fine now and it's not hard to transfer socket programs to linux, and java is a good choice.
uze6666 wrote:Btw, I can't recall if I saw it somewhere, did you wire up your Uzebox and esp8266 and connect to the chat server using my demo program?
Yes, I mean, I knew it would work, but when I actually saw it work it I literally shouted "YES!!" :lol: I tried making a (hideous) perf-board version, and the thing didn't turn out well for me. Right now I just have the direct 5v setup on a breadboard, but it is really sketchy on my messy work bench and the firmware I upgraded to has a much longer startup text and resets the whole Uzebox and the AD725 doesn't come back without hard power cycle?? Could be the direct 5v thing. So I have to disconnect the RST pin, manually reset it, reset the Uzebox then it works..so it's not realistic for development right now...I need a real PCB badly, but I can get it online if there are tests you want to try.


Edit-My uzebox is up on the chat server spamming messages with the ESP8266 running at 5v and I'm going to see if it's still alive in a week :)
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

My PCB fab in china will close shortly for a couple week for their "spring festival" so I had to send something ASAP. I made a PCB for the Uzenet daughterboard with the ESP-01+ESP-05 and SPI RAM footprints. I don't like the module protruding that much (due to the header) so I'll have time to rework the design to use another ESP version that uses a castellated pinout. This will allow the module to be soldered flat to the PCB. While at it, I could have all the other parts SMT!
Image
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

The card looks good, I need one!
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

D3thAdd3r wrote:The card looks good, I need one!
Oh you will! :D
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

This is probably just a long an rhetorical post here but I'm on a mission:

I am putting together a system of common functions to abstract how the ESP8266 actually works, into something a lot cleaner for a developer. Otherwise I think it will be too intimidating to be common. Even with the current buggy uzem 8266 support we can develop and test concepts for networked game demo right now(though until the Tx code is done, it will be jittery at best). I have been thinking about this, and I am leaning towards the idea that non-padstate networking is not unrealistic for many games as long as there are working examples of the theory. I think the best thing to get working first, as a good tutorial even, is a networked version of Megatris. Obviously it was the real flag ship game for the console and everyone has played it, and it's hard to find someone who doesn't enjoy it at some level. Besides, it's a great competition game, has some resources left in the build, and lends itself nicely to non-synchronous networking ie. not padstates. Open source tetris AIs are around, run an AI server on uzebox.net, and there is the "VS CPU" mode I always wanted-distributed computing is limitless.

I showed that padstates can be drop dead easy, but doing it any other way, I would say, looks complex as hell at this point. Megatris I suspect will not be that difficult and I will write up a tutorial as I go, improve ESP8266 emulation in Uzem as I discover it's shortcomings during the development, and for any of this to work well I need Alec to add Tx buffer code :P I will also need to finish a simple gameplay server for uzebox.net too, so I'm not saying this will happen overnight but it's my main focus. The general overview of how it will work is: each Uzebox will send the state of it's entire well(compressed) to the server as fast as possible, the server will send it to the other client. Now no matter you did you are looking at their well slightly in the past, that's internet gameplay, doesn't matter, think of them as separate threads. The server is just a data mediator but not the authority, the clients are trusted not to cheat.

The only time we need calculate "what happened first" happens to be the only way players really interact with each other: when garbage is sent over. You could get picky and calculate dead reckoning into the past to determine if garbage should have been in their well, before they finished planting a piece(that finished a line), that, depending on which happened first, would have caused a game over by filling the well or to have enough space left by clearing....yeah, screw all that stuff. When the client hears about the garbage you sent, he will add it to his well and from there you will see the garbage in his well appear, since he's constantly sending you well states as fast as possible anyways. It would be only an extremely rare situation where that would make a real difference, and in that case latency plays no favorites. Play with lower ping people if you are that much of a purist :D

Besides that general concept I know will work, the details aren't too radical. Since well states come rapidly and we only care about the newest available, use UDP packets with a time stamp. On receiving packets, discard any data older than what we already know about(packets out of order) since it's worthless. There must be a way to send reliable messages over UDP, so make a message ID/acknowledge system....no, forget that too. There is no cost to having multiple connections open on the 8266 and conveniently we can automatically have well state and message states separated. One connection is UDP for latency sensitive well data, the other one is TCP so we don't need to waste code space for a reliable message system for garbage. Let the module do all that work in it's TCP/IP stack. A well is 10*20 and there are 8 possible states for each 1(empty,color1,color2,etc) so 3 bits per space. We can send a compressed well state easily using only (10*20*8)/3 = 534 bits = 67 bytes @ 38400 baud = ~60 network frames a second: it should be silky smooth on even mediocre internet connections.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

Sounds all good to me! I'll work on priority on that tx buffer in between enlessly making kits for adafruit (geez where to attack ucc2015?).

Some bad news. Last week I had noted that one response from the chat server via the esp8266 missed a character in the middle. This is very annoying since I don't think the chat server or the 866 is at fault. I had noticed the same thing rarely happened with the Redpine module and the MIDI interface that would glitch sometimes. It's a transcient issue that I can't reproduce so it's hard to kown what is going on. Either there's a bug in the RX buffer, some race condition when reading from the main program or the UART circuitry has random glitches due to overclocking. I'll have to think about way to force the glitch.

In the meantime we wil need to include in the packets some checksum in order to discard bad ones.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote:I'll work on priority on that tx buffer in between enlessly making kits for adafruit (geez where to attack ucc2015?).
You are swamped with Uzebox work, no hurry of course. I would even take a stab at that part. But with recent chip burning disasters on my half baked setup, I think I'll wait until you release your add-on version before I try real hardware again. Just my bad guy opinion here; myself I love UCC as much as anyone. This year if only one could happen UCC or major development on Uzenet like add-on/new PCB revision/tx buffer/real multiplayer games, I'd say the later was more important for the platform.
uze6666 wrote:Last week I had noted that one response from the chat server via the esp8266 missed a character in the middle.
:shock: Ok bad news indeed, at the point I decided my 8266 was dying a 5v death I noticed the same thing and attributed it to my chip abuse. It wasn't very often, but it was always exactly the same character it missed(I only had it sending the same message repeatedly, is this your experience also?). If I had hardware working I'd test, but my fuzzy memory of the message I was sending tells me it was always about the 50th character. I don't recall if it was the same spot on both consoles. I'm useless on that without hardware right now, but do you think shifting it a little bit further from the HSYNC would do something? I never seemed to notice it happening on the Tx side did you?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

but it was always exactly the same character it missed(I only had it sending the same message repeatedly, is this your experience also?
For me, it was happeing randomly. However I never sent messages with the same pre-conditions.
I never seemed to notice it happening on the Tx side did you?
Neither for me so far.
Post Reply