Internet/network Communication

[mjs]

This is my suggestion:

Code: Select all

open "TCP:127.0.0.1:80,nb,server" for binary as #1
open "TCP:127.0.0.1,client" for binary as #2
open "UDP:127.0.0.1,client" for binary as #3

nb = non-blocking

So the TCP/UDP extension would fit into the "normal" scheme (see OPEN "COMn:" in your QB ...).

Regards,
Mark

[Shadowwolf]

well if you got the access mode token there why not use it ?
seems a bit messy to have all the primary information encode in the string

[DrV]

Adding more keywords is not a desirable thing IMHO...

[Shadowwolf]

hmm i was just thinking about this and encoding all the information in the string might not be a bad idea since you might want to to change the socket connection at runtime and i don't think you can change access mode information at runtime with open as it is.

but i don't like the idea of binary for the file mode. somthing like SOCKET would be better.

then you could have string flags control blocking/non blocking like mjs has shown. you could still have the automagical defult mode were it will do all the work for you i.e. connect with blocking etc. but you should also have a flag that will basicly give you direct controll over the socket.

[chris319]

Code: Select all

open "TCP:127.0.0.1:80,nb,server" for binary as #1
open "TCP:127.0.0.1,client" for binary as #2
open "UDP:127.0.0.1,client" for binary as #3

That's not a bad way to go. How about a more consistent order within the string:

address, port, client/server, protocol, blocking

So you could connect to a web site with a minimalist statement such as

Code: Select all

OPEN "192.168.0.1:80" FOR BINARY AS #1

alternatively

OPEN "192.168.0.1:80" FOR SOCKET AS #1

and TCP blocking client is the default. Your example would then become:

Code: Select all

OPEN "127.0.0.1:80,SERVER,TCP,NB" FOR SOCKET AS #1

[Shadowwolf]

hehe nitpicking here but if you set up a SERVER mode

OPEN "127.0.0.1:80,SERVER,TCP,NB" FOR SOCKET AS #1

then the IP information isn't need just the BINDING port but i guess it could be left in there for BSD support.

[mjs]

but i don't like the idea of binary for the file mode. somthing like SOCKET would be better.

The reason why I selected BINARY instead of SOCKET is that I personally like the way to see a socket as a "normal" file I/O stream. There is IMHO no reason to introduce a new keyword here ...

EDIT: There's another reason why I chose BINARY instead of SOCKET: For other file handlers, you might want to support OUTPUT, INPUT, and APPEND too to take care of all the different line ending stuff, etc... (weird world of portable software development).

For all the crazy guys:

Maybe we can think about a "plugin" feature to allow users to develop their own "protocol". Something like this (pseudo-code):

Code: Select all

sub register_my_handler constructor
    OPEN REGISTER "PROTOCOL:", open_function, close_function, read_function, write_function, seek_function
end sub

This "constructor" function gets called before any other code in your application but AFTER RTLIB initialization.

And whenever a file name starts with "PROTOCOL:", the user defined functions might get called.

This would allow a FB user to implement a file access over FTP: or HTTP:

But PLEASE don't take this thoughts too serious ... they are just some ideas floating around in my head ...

then the IP information isn't need just the BINDING port but i guess it could be left in there for BSD support.

You have to specify the IP address when you don't want that your application binds to all network interfaces. In other words: Specifying an IP causes that your application only listens on a single IP and not all the machines IPs ...

Regards,
Mark

[chris319]

I prefer "SOCKET" simply for clarity and readability. If it's functionally the same as BINARY, so be it. Adding one keyword isn't going to weigh down the language that much.

Code:
sub register_my_handler constructor
OPEN REGISTER "PROTOCOL:", open_function, close_function, read_function, write_function, seek_function
end sub

This "constructor" function gets called before any other code in your application but AFTER RTLIB initialization.

Welcome to freeBASIC++

:-)

[Shadowwolf]

the binary thing i still don't know alowing it to support other files mode would be strange also woudn't it make coding the new support alot harder if you see socket being used then you know excaley what to do and how to hook the functions.

but with binary or any other file mode for that matter you be force to parser the string in every case checking for flage type's in the string at runtime that alot of extra overhead that is simple not needed. it also incress the risk of somthing going wrong.



about the multiable ip thing hehe who is going to have multiable ip address expected for people running a real server.

[mjs]

One reason why I'd prefer the protocol prefix is that the user might be able to define is own ones ...

Another reason (and this is what I had in the back of my head ...) is that you should be able to nest them:

Code: Select all

OPEN "ZIP:{ZIP:zip_file_in_filesystem.zip:/zip_in_zip_file.zip}:file_from_zip_in_zip_file.txt" FOR INPUT AS 1

Just another crazy idea *g* ... maybe we can use a scheme similar to the one wxWidgets uses:

Code: Select all

OPEN "zip_file_in_filesystem.zip#zip:zip_in_zip_file.zip#zip:file_from_zip_in_zip_file.txt" FOR INPUT AS 1

Regards,
Mark

[DrV]

Just so you know, the typical UNIX sockets implementation has sockets as regular filehandles (opened with socket()) that can be read() etc. That is a good enough reason for me to use BINARY rather than SOCKET. I don't understand what you mean about "woudn't it make coding the new support alot harder if you see socket being used then you know excaley what to do and how to hook the functions. "...

Adding a SOCKET keyword would make a lot of people mad when they have to change all of their sources that use SOCKET as the name of a type or variable; adding new keywords (especially when not necessary) is a BAD IDEA. :)

I think the extensible protocol idea looks pretty interesting.

[Shadowwolf]

do you really want every function that handle file i/o to parser through ever string at runtime to see if it file i/o or socket?

for example what if a person did this

DIM temp as string
Temp = "TCP:127.0.0.1:80,nb,server"

open temp for binary as #1


if this type of thing is alowed then every case of binary being used the runtime will have to parser outall the information in the string and determin what the intent is.

but if there a socket token the compiler knows perfectly what to do with the string and asummes it socket information.

in the rtl
int fb_FileOpen( FBSTRING *str, unsigned int mode, unsigned int access,
unsigned int lock, int fnum, int len )

all you have to do is just the mode passed is SOCKET then you send it off to the socket lib easy fast and no overhead of first parsering out information every time you make a call to FileOpen

to fix the name problem then

BSD_SOCKET

[Shadowwolf]

damn it i just relized there already presdent for runtime evaluation of the string for intent from qb with open "com1:". oh well can't make a argument agaist somthing when it's fallowing along with already estiblished convention.

but to get , get/put working correctly is going to be tricky. if intent can only be worked out realtime then the runtime lib going to have to be reactive to this possible conditation or maybe fb_FileOpen could reset fb_fileTB mode flag to a special mode. so that libfb_file_get can reacted to it and pass it to a the socket get function.

[dumbledore]

open "com1:" doesnt work in fb :P
(but open "cons:" does, and so does open "pipe:")

[jofers]

That's because Windows doesn't offer direct serial access like DOS did, you have to go through a modem driver, or whatever driver for whatever you have plugged in there. That's why crap like OpenGL and the WinAPI are important, because all the drivers are written for them.