#25 connecting kidbasic instances?

[Anonymous]

this is something that occurred to me just recently: it would be very educational to have a simple way to connect several instances of kidbasic, for example using a simple TCP/IP socket connection to connect two instances, so that they can talk to each other - this could probably be added with just 3-5 new commands (something like open, sendmessage, waitmessage and close). This would allow kids to see how many modern programs and technologies (such as the internet) are working.

A simple kidbasic program could look like this:

echoserver:
message$=dim(128) ; allocate buffer for message
sopen "127.0.0.1:8888" : open a socket on localhost
message$=waitmessage : wait for a message and store it
sendmessage message$; echo message back
sclose

[Nobody/Anonymous]

while the syntax you are proposing is a bit weird and not necessarily in line with the rest of kidbasic, the idea itself sounds indeed interesting

[Nobody/Anonymous]

maybe it could be as simple as having new commands like "talk" (or "tell") and "hear" for multiple instances to "talk" to a shared connection buffer and "hear" (listen) for messages to be parsed, abstracting away all the low level details of sockets, just by enabling instances to talk to one another.

[Nobody/Anonymous]

actually, something like this would also be neat to reimplement the pong game, so that two instances can be run on different computers, it could illustrate how multiplayer gaming works behind the scenes

[Nobody/Anonymous]

I agree such a feature would be powerful to illustrate important modern concepts such as server/client technology.

So if there is some interest in this, and people think that having such features makes sense, I'd be willing to look into this, how would this supposed to be workin?

I am thinking of just using plain TCP sockets, so that an address and port number must be specified. This would keep it pretty flexible, so that kidbasic instances could be connected using conventional network technology (abstracting away the lowlevel details of socket ops), on the other hand shared memory IPC is also easy to do, but would restrict everything to one single machine.

Another thing to keep in mind is that people may want to connect more than just 2 instances, i.e. in a peer to peer fashion - which would probably be better implemented using UDP as the low level building block?

I really like the idea of just providing one abstract "send" and "receive" command that could be used to send arbitrary kidbasic primitives to another instance, not just in a client/server fashion, but also for peer <-> peer ops.

Also, is an address and port number really required? One could just as well use a kidbasic specific number that consists of an encoded 32 bit integer address, plus the corresponding port number.

How simple or powerful would this need to be?

Should we maintain the notion of a machine address and port number?

[Nobody/Anonymous]

I absolutely like this idea because it would provide a way to allow kids/new programmers to create a simple echo/http server, which they could connect to using their browser, so that kidbasic could be used to come up with a "hello world" example that can actually be used from a browser.

I think this would be pretty educational, because kids would get to see how a web server works behind the scenes, but I agree that it should remain very simple.

The intriguing thing about this is that a client/server capability would be a technology enabler, as it could be used to illustrate many other more advanced concepts and things, so kidbasic would no longer be isolated in its own world, but could really interact with other programs and services.

For example, by having a command to get a handle to a binary blob of a customizable screen region, it would even be possible to dynamically create images using such a server, and then send those as MIME encoded jpg/png to the connecting browser client.

This would probably be just 2-3 new commands, but would basically have all the power of imagemagick/GDLib in kidbasic.

A very simple program could emit an HTTP form to allow the user to draw a circle with a configurable radius and color, so that the kidbasic program draws the circle accordingly, and transmits the MIME encoded binary blob for the corresponding screen region to the client.

I think this would be a fairly neat feature to have, because it would show the applicability and real use of kidbasic programming for real life programming, as it is being done nowadays without being confined just to the programming environment that kidbasic itself provides.

A simple echo server or HTTP server done in kidbasic, would probably be one of those eye opening moments, when people new to programming realize how all this youtube, facebook and myspace stuff is working behind the scenes.

Qt already provides QTcpServer and QHttp classes, so it should be fairly easy to do something lke this.

[Nobody/Anonymous]

I am looking into this now, it was fairly simple to add new commands to the lexer and interpreter, and I have them working now. The question is how the syntax is supposed to be looking, there are various feasible ways.

But at the moment I am inclined to simply overload the file I/O functions (open, write, read, close etc) so that they can also be used for doing network I/O.

But ideally, I also want to support TCP and UDP, as well as client/server use:

proto "udp|tcp"
open "google.com",80
write "GET HTTP/1.1\n\n"
response$=read
close

What do you think, is this too low level??

The alternative would be to just have very abstract "send" and "receive" commands, with URL encoded protocol, host, port:

send "tcp:google.com:80", "GET HTTP/1.1\n\n"
response$=receive

where all the housekeeping stuff would be handled behind the scenes

[Nobody/Anonymous]

I just mentioned this in the other suggestion, personally I am more in favor of providing a more abstract concept than just sockets, maybe something like a "channel", which implicitly binds a socket to localhost and uses port 80?

Maybe with an option to override these defaults, for talking to programs that are not running on the same machine...

In most cases, there would then just be a conventional "channel" as a wrapper on top of tcp sockets, which could then be read/written to for talking to other programs.

By convention, everything would be blocking I/O to make things really easy to grasp - for example, reads wait for data on the channel, while writes only finish when the message has been received.

[Jim Reneau]

I have been listening to the discussion and have had a few ideas myself. File i/o was changed recently to allow multiple files open and I am not in favor of overloading the original statements (can make them confusing).

Here are the statements I have thought about

NETLISTEN port
- start listening [server] on a port
- do we make this blocking until a client connects or do we require
- the server looping waiting for a NETCONNECTED = true?
NETCONNECT ipaddress, port
- connect to server
bool = NETCONNECTED
- function to return if the server has a client connected or the server is active
NETWRITE string
- blocking write either from server to client or client to server
v$ = NETREAD
- blocking read
bool = NETDATA
- function to return true if there is data waiting to be read
NETCLOSE
- close either the server or client connection

ONERROR was also recently added to GOSUB on a run-time error. Similar statements like:
ONNETCONNECT label
- gosub to label when server gets a connection (one time fire) so that server does not get too conflicted with multiple clients
ONNETDATA label
- gosub to label when client or server has a read pending (one time fire)

Simple program might look like:
NETCONNECT "www.google.com", 80
NETWRITE "GET HTTP/1.1\n\n"
print NETREAD
NETCLOSE

Low-level socket programming is something I have not had much experience with and will need help to implement the code in the interpreter.

[Nobody/Anonymous]

Hi,

I just took a look at the latest code in the repository, and I think this is really neat and useful!
However, I was wondering what you guys think about overloading the net* functions to support an optional handle parameter?

That way, it would be possible to create multiple different connections, and refer to them using an optional handle - whereas by default, the netwrite/netread commands would resort to the first open socket?

I am thinking in terms of supporting multiple connections, where having a way to use a handle would be useful:

handle=netconnect "127.0.0.1", 9997
netwrite handle, "Hello World"
netread handle
netclose

[Nobody/Anonymous]

And to add to this: Having a "netproto" command to select tcp vs. udp might also be useful at some point?
And maybe this could be implemented as reliable UDP (with numbered acknowledge packets).

I am looking forward to use this for implementing a basic server, and maybe a CGI at some point!

[Nobody/Anonymous]

For turning this into cross-platform code, I would look into using the Qt socket classes: http://doc.qt.nokia.com/4.0/qt4-network.html

[Nobody/Anonymous]

Okay, I took some time to play around with the new commands, and it seems this is already powerful enough to re-implement parts of the ping game to turn it into a classical "pong" game with two players, who would use two instances of basic256, possibly even on different machines - like true multiplayer :-)

For pursuing this route, one might add an "show public IP address" entry to the about menu, so that users can easily see their current IP

[Nobody/Anonymous]

> overloading net* for multiple connections

This is apparently now being worked on, there is now code in the repository for dealing with multiple connections using nix style select facilities.

[Jim Reneau]

Similar functionality added to 0.9.6.31 - see documentation.