RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Bounties →

TCP/IP Stage 2 bounty

Subscribe to TCP/IP Stage 2 bounty 72 posts, 24 voices

Posts per page:

Pages: 1 2 3

 
Nov 29, 2019 10:37pm
Avatar Michael Drake (88) 312 posts

Where’s GCC 8? NetSurf’s autobuilder is still using GCC 4.7 for RISC OS builds.

The latest I can see on the gccsdk site is gcc 4.7: https://www.riscos.info/index.php/GCCSDK_Releases

 
Nov 30, 2019 10:23am
Avatar Timo Hartong (2813) 185 posts

@Andrew : Timo – please drop me a line at the riscosdev.com email address => Done

 
Nov 30, 2020 8:31pm
Avatar André Timmermans (100) 386 posts

Since it was announced by Andrew at the latest show that the port of the latest BSD source reached a state where someone just used !Netsurf with the port for the first time, why is the state of the Bounty still ‘Open’ instead of ‘Underway’ ?

Edit: I guess that’s because the donations didn’t reach the target yet.

 
Nov 30, 2020 9:41pm
Avatar Richard Walker (2090) 331 posts

I assumed that it was a ROD/Andrew organised effort, and so the bounty may not apply. I found Andrew’s talk about it most interesting, and was excited to hear that someone was working on it.

Maybe they will see how things pan out and throw some code (rather than cash) at the ROOL GitLab?

 
Nov 30, 2020 10:57pm
Avatar Steffen Huber (91) 1644 posts

I guess that’s because the donations didn’t reach the target yet.

If I understood the bounty system correctly, that can never be the case. The “guide target” is just that: a value estimated by ROOL on how much effort the bounty might need.

If there is no developer interested in making the bounty happen, it will never change to “Underway”. If there is a developer interested in making the bounty happen even if it as only gathered 1 UKP of donations, it will change to “Underway”.

Andrew explained that the new TCP/IP stack he talked about was NOT funded via the ROOL Bounty system, but by a commercial customer.

 
Dec 1, 2020 4:17pm
Avatar Michael Grunditz (8594) 75 posts

Where’s GCC 8? NetSurf’s autobuilder is still using GCC 4.7 for RISC OS builds.

Newer GCC is in autobuilder. I think you need to build it.

 
Dec 1, 2020 5:37pm
Avatar DavidS (1854) 2151 posts

Does this mean that we may see a bit newer compiler also? In other words if the Autobuilder is able to use GCC 8, how much other work is involved in getting it ported to run on RISC OS?

To be completely honest, I have never looked at what it takes to port GCC, where possible I use smaller compiler toolchains, and on RISC OS I currently use GCC because that is what we have other than the DDE, and I do not have a recent DDE. Though I may have to actually look at what it would take to get TCC going, good non-optimizing option for things that make sense not to need optimization.

 
Feb 19, 2021 6:00pm
Avatar Bryan (8467) 215 posts

Incidently, does this bounty include online documentation of all of the SWI interfaces (ie not C interfaces as in PRM 5a).

Or have I missed something? (again?)

 
Feb 19, 2021 8:36pm
Avatar Rick Murray (539) 10566 posts

Aren’t the SWIs basically just OS friendly wrappers around the standard C functions? A BASIC program can’t call listen() but it can call Socket_Listen()…

 
Feb 19, 2021 11:14pm
Avatar Bryan (8467) 215 posts

Aren’t the SWIs basically just OS friendly wrappers around the standard C functions?

Surely, it is the other way round. The SWIs came first. They are designed to be called by assembly language software, or even BASIC, both of which existed without C.

 
Feb 19, 2021 11:56pm
Avatar Chris Mahoney (1684) 1687 posts

As I understand it, the socket stuff came from BSD and was originally in C, so the SWIs are indeed wrappers around C.

 
Feb 20, 2021 8:47am
Avatar Bryan (8467) 215 posts

I stand corrected. Now I understand why this bounty exists.

 
Feb 22, 2021 4:11pm
Avatar Bryan (8467) 215 posts

In a number of topics, there have been requests, not just from me, asking for simple examples of socket software written in BASIC. There have no such simple examples given.

I suspect that this may well have been a major incentive for Justin to write his Easy Sockets module and for Roger to write SocketFS.

I have dusted off my copy of EasySockets and Aemulor and produced a simple example of an HTTP Client program.


SYS “XESocket_ConnectToHost”,host$,new_port% TO handle%
REPEAT
< wimp poll >
SYS “XESocket_CheckState”,handle% TO state%
UNTIL state%=4
SYS “XESocket_SendData”,handle%,request$,LEN request$
SYS “ESocket_ReadData”,handle%,reply_buffer%,200 TO ,,len%
SYS “XESocket_Forget”,handle%

It is now a day or two over 19 years since Justin produced version 1.18 of EasySockets.

Why do we still not have any other way to easily write socket software in Basic?

I have come to the conclusion that, at best, The Internet module SWI wrappers are very difficult to use; and, at worst, not really fit for purpose. Meaning that those of us trying to write socket software in BASIC have a very uphill struggle.

 
Feb 22, 2021 4:40pm
Avatar Alan Adams (2486) 511 posts

Why do we still not have any other way to easily write socket software in Basic?

Because using sockets isn’t easy. That’s not a feature of BASIC but of sockets.

It is possible to create a fairly simple app, if you accept that the operation will block whule waiting for a response from the socket. It’s also possible to use Easysockets to do some operations. However if you want a system where things communicate over TCPIP in a fully non-blocking fashion, and allow for broadcast messages (to estabish links for instance), link status checking etc, you will need to bite the bullet.

Understanding what needs to happen can be difficult. When I started doing this about ten years ago, Druck supplies me with a version of his socket library ported to BASIC, which was a great help, as it covered the lowest level bits. It’s still necessary however to uunderstand the steps needed to set up a link, to send messages across that link, and to check whether messages have been received (in non-blocking fashion) and read them.

Most of the work can be done in a null poll loop. If you also use Socketwatch, you can move this to a loop called from the pollword-changed return code. In practice I find the code for both is the same, so both returns call the same code. Socketwatch allows a faster response, otherwise you can only check every 10mSecs, which means a client-server dialog uses an average 10mSec for each message/response pair.

Detecting that a link has stopped working is an extra problem. If the far end client closes the link, the near end is notified. If the far end crashes, or the cable gets unplugged, there’s no indication until an attempt to send to it fails.

The only real complication due to the BASIC language is that you may be dealing with messages longer than 254 bytes, so using BASIC strings is not possible. Instead you need to use buffers, set up with DIM statements, and accessed by indirection. If you use TCP rather than UDP, then there is no guarantee that a message sent as one block of data will arrive in the same way. The packet may be split into two or more pieces, and you need to allow for this possibility. In my case, each message has a unique end character, so if received data doesn’t include it, I set up another read to get more and continue doing this until I have the end character. I use ring buffers, to avoid too much copying of data, but this does mean that a message may begin towards the end of a buffer, and wrap around so it ends near the start of the buffer. This produces edge cases that need careful testing, e.g. the message ends exactly at buffer end, or the only character wrapped is the final one, or the first character after the real message is an end character left from previous buffer contents.

Most of the above would also apply to C code, but the extra performance of a compiled language might mean some optimisations could be skipped. For example a message could be copied out of the input buffer, and the buffer reset to empty, eliminating the issues related to ring buffers. String processing in C might be possible where it is not in BASIC. (I’ve never written any C, so I don’t know what might be possible there.)

 
Feb 22, 2021 5:08pm
Avatar Richard H (8675) 49 posts

Yes, sockets are hard.

Not BASIC-related, nor even directly RISC OS-related, but for those people struggling with socket programming, may I recommend Beej’s Guide? I remember reading this aeons ago, when I was first learning network programming, and it remains, I think, an excellent tutorial on the hows and whys of socket programming. I’m pleased to see that it is still available, even updated.

https://beej.us/guide/bgnet/

 
Feb 22, 2021 5:17pm
Avatar Colin (478) 2294 posts

I have come to the conclusion that, at best, The Internet module SWI wrappers are very difficult to use; and, at worst, not really fit for purpose.

Not really the internet module swis are just standard socket functions and the C library are just a wrapper to these swis. I think basic tends to get ignored because to learn to use sockets you need to read linux examples/tutorials and they are all in C so the easiest way to follow them is to use C on riscos which has a very similar socket library to linux. The problem with modules is that there is far more to a socket library than functions so half the information to use the module from basic is missing – you basically have to translate structures/constants from the C library. At this point having learnt sockets you give up on BASIC – you could translate back to BASIC but why bother.

I’ve not used EasySockets but generally find the problem with simplified libraries is lack of flexibility. You could just as easily have written a BASIC library using internet swis which does the same thing as your swis – once you now what you are doing :-). On the other hand I know how to use sockets and I would have questions about your code outline that I’d want answering before I used the module as you have shown – hopefully the documentation clears up my problems.

Sockets generally are an uphill struggle and it is much easier to rely on linux for documentation/tutorials/troubleshooting making C easier to use.

 
Feb 22, 2021 7:47pm
Avatar Colin Ferris (399) 1058 posts

I wonder if Gerf would allow a 26/32 release of EasySockets?

 
Feb 22, 2021 9:18pm
Avatar David J. Ruck (33) 544 posts

When I started doing this about ten years ago, Druck supplies me with a version of his socket library ported to BASIC

I’m happy for anyone else to have it, if someone can suggest somewhere to put it (politely!)

 
Feb 22, 2021 10:36pm
Avatar Alan Adams (2486) 511 posts

I’m happy for anyone else to have it, if someone can suggest somewhere to put it (politely!)

I did have to make one correction that only shows up if the computer is using more than 32 sockets. There’s an offset of 1, expecting words, but interpreted as bytes, so should be 4. My errors in programming have on occasion taken the socket count up to the limit of 96. (Why 96 – I would have expected a power of 2, i.e. 128?)

 
Feb 23, 2021 9:02am
Avatar David Feugey (2125) 2573 posts

I’m happy for anyone else to have it, if someone can suggest somewhere to put it (politely!)

May we have it sir? :)

 
Feb 23, 2021 9:17am
Avatar Colin Ferris (399) 1058 posts

It would be very nice to be able to download a copy.

Having a copy on Druck’s own web site – as well?

Has anyone done a ‘flow chart’ of internet connections?

[edit]

 
Feb 23, 2021 9:55am
Avatar David J. Ruck (33) 544 posts

@Alan please can you let me have that correction.

 
Feb 23, 2021 12:00pm
Avatar Alan Adams (2486) 511 posts

@David
bq. please can you let me have that correction.

I’ve put the revised library here http://www.adamshome.org.uk/RiscOS/socketlib.zip

When I looked at the commented changed bit I couldn’t see what the original had been. Maybe using !SideDiff with your version would be the best way.

I changed max sockets to 128, not knowing at the time there is a system limit of 96.

 
Feb 23, 2021 1:48pm
Avatar Bryan (8467) 215 posts

@David and @Alan

Thank you for the library.

On the assumption that you are happy with comments here, so far I have PROCSocketLib called with DEBUG% previous set to zero.

With no further routines called, when exiting my task and calling PROCSocketLib_CleanUp, I get an error at line 173 because FNisvar does not appear to be avilable. Commenting the line out allows the Cleanup to complete.

Also File name ‘.LIBRARIES.HOSTS’ not recognised in “Libraries.SocketLib”

Sorry Folks,
This is no easier than calling the SWIs direct. I still need a simple working example.

 
Feb 23, 2021 3:44pm
Avatar Alan Adams (2486) 511 posts

@bryan Sorry if I’ve confused you. The link to the library was intended for David, so he could incorporate the bug fix into his library. (I don’t this forum supports private messages.)

My version, as you’ve discovered, has some other changes, although I had forgotten how many. FNisvar is in a different library, and is used to test if a variable exists before using it, so as to avoid “no such variable” errors. Hosts is a copy of the system hosts file, used to resolve names when the environment isn’t fully set up for name resolution. It may actually be redundant in my system now, so I need to see whether it can be removed.

Next page

Pages: 1 2 3

Reply

To post replies, please first log in.

Forums → Bounties →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Discussion of items in the bounty list.

Voices

  • Michael Drake (88)
  • Timo Hartong (2813)
  • André Timmermans (100)
  • Richard Walker (2090)
  • Steffen Huber (91)
  • Michael Grunditz (8594)
  • DavidS (1854)
  • Bryan (8467)
  • Rick Murray (539)
  • Chris Mahoney (1684)
  • Alan Adams (2486)
  • Richard H (8675)
  • Colin (478)
  • Colin Ferris (399)
  • David J. Ruck (33)
  • David Feugey (2125)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys