Hi Brian,
Since I never persued the network.dll, your routine will be of great help.
In parallel, your chosen example is educative
Thanks a lot for sharing it.
Robert
Thanks to your post I checked the dict.org site exploring all
its query features. I felt that more information is provided
via HTTP access and wrote a little app that sends a query string,
parses the returned HTML file and displays the result.
I still have to work on formatting the result text.
Help File and Download CAB menus are still dummy functions.
BTW, how do you know whether a server allows TCP access
and the required parameters? A weather data server would be
nice for TCP access, wouldn't it.
Nice app! The HTTP approach will be very useful when talking to most web based apps. The TCP socket approach is lower-level, but useful when HTTP access is not present. I started playing with network.dll to figure out how to create a Basic4PPC version of my remote technical support software for handhelds. It's basically on demand remote technical support for multiple platforms.
Regarding TCP access to various servers, the process ranges from reading RFCs and documentation to black art. Dict.org is such a great example because it is free and fairly well documented, although reading RFCs is not exactly fun. This approach is the best learning exprience, IMO.
If you don't really want to know all the ins and outs of the protocol, it is often better to look for open source projects in other languages and port the code.
Here are a couple examples of what I use TCP sockets for and, in short, how I figured them out:
FTP - Read the RFCs and looked at open-source FTP code.
Flash - I wrote a TCP server that communicated with a Flash/Actionscript web page using Flash's XMLSocket, which is a limited TCP socket in disguise. After connecting to the XMLSocket and having it write data to my client socket, I looked at each character as they came in (using ASC) and figured out that Flash's XML socket terminates every command with CHR(0). Most protocols that use terminator-based commands use CHR(13) & CHR(10), aka vbCRLF, as the terminator. Once I knew the terminator, which is used for sending and receiving, implementing my own custom protocol was no problem.
HTTP + Proxy server + progress - Using a TCP socket, we can build an HTTP socket from the ground up. This can be useful, as shown in the FTP example, to get low-level access to the protocol, and get the ability to provide progress during downloads. I haven't looked for a HTTP download with progress project in Basic4PPc yet, but if one doesn't exist, I'll probably port my HTTP code.
Lastly, if you need to figure out a protocol using more brute-force methods, then I recommend using telnet to connect to the host on the specified port and see what you get. For example, if you telnet to a FTP server on port 21, and follow the sequence in my example code, you can manually type in the protocol commands in telnet. It's pretty cool. Another way to do this is to use a packet sniffer to watch the TCP conversation between client and host.
None of this is easy, but it can be very worthwhile. I hope all my rambling is helpful. Let me know if I can be of assistance.
Use Network.Client to get the definition of a word from Dict.org
Linear Mode
