I'm taking a break from php and CSS website development to get back into RS coding because I'm developing both a server backend and client apps using RS and I'm about to reserve my VPS so I'd like to know what I'm getting into concerning RS bugs.

It has been quite a while since I've written a lot in RS and even longer since I've been serious into sockets so I'm hoping this is my bug and not another socket bug in RS; for some unknown reason socket bugs seem to take forever to get fixed if they ever get fixed.

I have a project which needs to use the server socket, SSLsocket, httpsecuresocket/httpsocket and TCP sockets. With the serversocket and SSLsocket/TCPsocket I'm making a backend server.

With the httpssecuresocket/httpsocket and TCP socket I'm making the desktop clients. I may also make mobile clients but I'll probably use Corona for this.

While testing the serversocket's ability to handle incoming connections using SSLsecuresockets I created a client app which uses a timer to spawn and connect httpsecuresockets to a different serversocket app which is using the SSLsockets and here is where the problem is. In 2010 and 2011 my client app seems to work no problem. But when I run the same app in 2012 (all versions) the client app crashes after what seems to be the first successful connect. Sometimes at the bottom of the IDE I see a Nil object exception error, other times I just see a '-' symbol.

Here's the details about my test client app which uses a timer to spawn and connect to the serversocket.

Under the project tab I created a new class named myhttpsecuresocket with a super of httpsecuresocket.

In app I created a property connectsocket as myhttpsecuresocket with a public scope.

I verified port, address and connection type are correct.It doesn't make a difference if the timer fires every 10 seconds or every 200 ms. Same results.

When developing this with 2012 I couldn't figure out why it wasn't working. I figured I must have forgotten something and I'm doing it wrong. Then it occurred to me this might be another RS bug so I'd better try older versions and they worked.

Did I forget so much RS I've errored ?

It works in 2010 and 2011 so why not 2012?

Does anyone know of any httpsecuresocket or httpsocket bugs in 2012?

2012 UPDATE :When the client app is running and there is no listening serversocket to connect to, the client app continuously spawns the new sockets without getting the Nil object error or any crash. This makes me think something internally is going wrong after the 2012 socket connects.

For the actual server backend I plan on using a console application which I have not tested yet. Previously there were SSL listening issues that prevented it from working and I don't know if they've been fixed yet. In typical fashion RS staff ignored my question about it.

So I also need to know if the serversocket with (listening) SSLsockets is working correctly in console apps for Linux, Mac and Windows if anyone happens to know?

I'm currently testing this on Mac OS X 10.6 but I also need this working for Linux (Unbuntu) and Windows.

Not surprising as soon as I take a break from php and web development and return developing in REAL Studio I immediately find another critical bug. 2012 was supposed to be their best effort in quality and in less than 2 hours I hit another critical bug with a major feature.

timhare wrote:

But you gotta ask yourself one question : do you feel lucky?

I don't think I should answer that one.

timhare wrote:

No, I mean, you gotta ask yourself one question: do you really want to implement the server side in RB?

If it works, yes.I already do use php for the backend on other projects but for this project and other projects I want my server backend compiled. This and other projects I may sell to the public which is why I need it compiled. I know I don't have to tell you php is naked and unprotected and that it's also harder for many people to configure (if not already on their VPS/server) than a compiled RS app.

They market and sell REAL Studio as a professional level development tool but so often when I try to develop projects that I need to create it has many critical bugs and bugs the customer can't fix.

All the while the RB cheerleaders pretend there aren't bad bug problems.

For this project I might still be able to make the backend using 2012 since this part seems to be working correctly. However, I have not tested for memory leaks which REAL Studio is so found of. I also haven't tested how the socket's react after some data exchange takes place.

I'm finding it a bit hard to understand what the problem you're experiencing is exactly.

If i read correctly, you're trying to spawn multiple connections in a normal property rather than an array? Have you tried it with an array and appending each new socket to that, so there is always a reference kept as the error might be down to sockets and RS's object reference counting?

If you dont want to use an array, try closing the socket before creating a new one in the same property.

You didn't specify what the server component does, so I tried recreating the client as you described it and having it connect to PayPal's https.

No crashes using RB2012r2.1 on Mac OS 10.7.5.

lukus001 had some good comments. The test client absolutely needs to keep references to open sockets, and should properly close them as well. Especially if you want a valid test (when a socket falls out of scope it should close on its own, so you're not actually testing multiple concurrent connections).

Aside from that, we would have to know a lot more to try and replicate the issue and help out.

No, I mean, you gotta ask yourself one question: do you really want to implement the server side in RB?

I cannot agree with the sentiment expressed here. I have developed and deployed multiple custom client/server socket apps for my clients using RB. They are fast and very stable. By "stable" I mean that they run without issue and without reboots for upwards of a year.

In this first test I was testing the functionality of the serversocket and the SSLsocket to see if and how well they work handling incoming connections, if SSL certificate working correctly, will it now work with a console app and secure incoming connections, etc?

This test was not yet about sending/receiving data, that comes later

The reason I want to use a console app is because as you guys know console apps use less server resources and possibly have better performance than a desktop version and there is no need for a user interface on a server app as most config/use will be via remote location. Though if I decide to later purchase a mac mini and run OS X server I may want to use a desktop version of my server app because I'd be able to remotely control the UI via UI, graphically.It really depends on the performance difference and server resource cost (ram, cpu, etc.).I have not tested the differences yet.

One concern is I remember there was and maybe still is a console app serversocket or SSLsocket bug where it wouldn't accept incoming connections, making it useless. So that will be part of my testing needs.

Over time I will have to test many sockets since often they are broken and the project I am making uses a lot of different sockets.

taylor-design wrote:

so I tried recreating the client as you described it and having it connect to PayPal's https.

No crashes using RB2012r2.1 on Mac OS 10.7.5.

Did you repeatedly connect? That seems to be where the crash happens.My example app connects and accepts the connection the first time without crashing.It's the later, successive connects that crash it in RS 2012.

Right now I'm guessing the crash is not on the server end but on the client side but I have not yet throughly tested. I haven't given it much time as I've went back to CSS and developing with website portion of this project so I'm doing my testing in my extra time and this bug brings back bad feelings of how broken sockets are in RS

taylor-design wrote:

lukus001 had some good comments. The test client absolutely needs to keep references to open sockets, and should properly close them as well. Especially if you want a valid test (when a socket falls out of scope it should close on its own, so you're not actually testing multiple concurrent connections).

Yes he did have some good comments but right now they don't really apply to this initial test, nor do they solve the crashing problem.

Scope shouldn't be a problem because it's a property of app so it never goes out of scope. I don't remember if reassigning the variable is considered a scope issue or not but it shouldn't cause a crash.

For my initial test I didn't need references and RS should keep it's own internal reference so that shouldn't throw an error. I wasn't interested (yet) in looping through on the client side since I was focused on testing serversocket and SSL socket receiving connections.

taylor-design wrote:

Aside from that, we would have to know a lot more to try and replicate the issue and help out.

Yes, that would be good, thank you Daniel I can email you the test project if you'd like to see the code yourself.

lukus001 wrote:

I'm finding it a bit hard to understand what the problem you're experiencing is exactly.If i read correctly, you're trying to spawn multiple connections in a normal property rather than an array?

Hi.Yes I was using a property of app so scope is not a problem and since I didn't need to loop through the connects on the client side I didn't initially use an array as I was focused on the serversocket testing.

lukus001 wrote:

Have you tried it with an array and appending each new socket to that, so there is always a reference kept as the error might be down to sockets and RS's object reference counting?

Yup, I also tried using an array on the client side, same result. I actually dug up some old projects which I've used socket arrays with.Ran fine on 2010 5.1, same crash on 2012.x as did my first test without using the client side socket array.

lukus001 wrote:

If you dont want to use an array, try closing the socket before creating a new one in the same property.

Yes tried that also, same results.

It is also possible the serversocket code I'm using is wrong, I haven't really gone over it much because it's working in 2010 5.1 but fails in 2012. That indicates either RS 2010 5.1 is buggy and my code is wrong but the bug failed to catch it, or RS 2012.x is buggy and the code is correct.

timhare wrote:

Sounds like a bug, to me.

But you gotta ask yourself one question: do you feel lucky?

No, I mean, you gotta ask yourself one question: do you really want to implement the server side in RB?

I do all my server code in php and write the client in RB using httpsercuresocket/httpsocket. Let the web server handle ssl for you. Plus, it's a MUCH smaller footprint on the server.

taylor-design wrote:

I cannot agree with the sentiment expressed here. I have developed and deployed multiple custom client/server socket apps for my clients using RB. They are fast and very stable. By "stable" I mean that they run without issue and without reboots for upwards of a year.

Daniel, you should consider that many experienced developers some of which are networking professionals are often complaining about the broken sockets / networking functions in REAL Studio / XOJO. I myself am not a networking professional but over the years I have used almost every type of socket REAL Studio offers and I can tell you there have been far too many bugs and broken things with the sockets. These socket bugs are my and many other customer's number 1 complaint about this product and they never seem to get fully fixed.

If your experience has been different to ours then I think this is because you don't use as many sockets as I and other customers often do?

I appreciate the help guys and I haven't gone over my code in detail yet but I'm still thinking this is an RS / XOJO bug

In this first test I was testing the functionality of the serversocket and the SSLsocket to see if and how well they work handling incoming connections, if SSL certificate working correctly, will it now work with a console app and secure incoming connections, etc?

What I meant was that I could not create a server app for the test that would be similar to yours. The client app description let me create something presumably identical.

Quote:

taylor-design wrote:

so I tried recreating the client as you described it and having it connect to PayPal's https.

No crashes using RB2012r2.1 on Mac OS 10.7.5.

Did you repeatedly connect? That seems to be where the crash happens.

Yes.

Quote:

I haven't given it much time as I've went back to CSS and developing with website portion of this project so I'm doing my testing in my extra time and this bug brings back bad feelings of how broken sockets are in RS

Sockets are not broken in RS. I can't rule out that you've found some bug, but I've been using sockets in high performance apps for years.

Quote:

taylor-design wrote:

lukus001 had some good comments. The test client absolutely needs to keep references to open sockets, and should properly close them as well. Especially if you want a valid test (when a socket falls out of scope it should close on its own, so you're not actually testing multiple concurrent connections).

Yes he did have some good comments but right now they don't really apply to this initial test, nor do they solve the crashing problem.

So you've tried implementing them?

Quote:

Scope shouldn't be a problem because it's a property of app so it never goes out of scope. I don't remember if reassigning the variable is considered a scope issue or not but it shouldn't cause a crash.

When you reassign the variable you are dropping the last reference to the socket. It's going to be garbage collected.

Quote:

For my initial test I didn't need references and RS should keep it's own internal reference so that shouldn't throw an error.

No RS shouldn't. That would cause a severe memory leak.

Quote:

Daniel I can email you the test project if you'd like to see the code yourself.

I would recommend placing a test project in a publicly accessible location so that everyone can have a look and try to help.

Quote:

taylor-design wrote:

I cannot agree with the sentiment expressed here. I have developed and deployed multiple custom client/server socket apps for my clients using RB. They are fast and very stable. By "stable" I mean that they run without issue and without reboots for upwards of a year.

Quote:

Daniel, you should consider that many experienced developers some of which are networking professionals are often complaining about the broken sockets / networking functions in REAL Studio / XOJO.

I follow the mailing list and this forum pretty closely, and sockets hardly ever come up. Who are these professionals, and what are their complaints? I just checked Feedback and there's not much open for the socket classes: feature requests and apparently a few issues with the debugger and sockets.

Quote:

I myself am not a networking professional but over the years I have used almost every type of socket REAL Studio offers and I can tell you there have been far too many bugs and broken things with the sockets. If your experience has been different to ours then I think this is because you don't use as many sockets as I and other customers often do?

LOL! I've probably written some of the highest performance / most highly stress tested socket based RB apps in existence. They run every day on servers in offices and cohosts.

I truly want to see this thread end in a solution for whatever problem you are experiencing. But...every time you have any sort of issue with a RB project, you assume it's because RB is "broken", and you end up spending half your time preaching about how "broken" RB is. Stop. Odds are it's not RB. And if it is, you need help from others to isolate, verify, report, and work around the issue. Telling someone that they're 'not really using RB' if they disagree about it being "broken" isn't a good way to elicit help. And it's a waste of time.

Don't write a long response about how RB is broken, please. Just post your test projects to a public server so other people here can have a look and try to help.

Sockets are not broken in RS. I can't rule out that you've found some bug, but I've been using sockets in high performance apps for years.

I'm busy working on my web work right now but I just wanted to reply to this one part of your post in this moment.

Those are empty words without any proof.If you honestly believe that then accept this challenge :

Find a single working version of REAL Studio in the last 4 years that all the sockets work correctly and for each OS supported. According to you if no sockets are broken and have not been broken this should be very easy.

I'm betting you won't do it because once you start testing the sockets you're going to find out how many things were and probably still are broken.

I hope I'm wrong about the current state because in the future I'll still need to use them a lot. Sadly the reality is many things with sockets have been broken and I doubt even now many years later in 2012 or XOJO 1 will everything with sockets work correctly.

Here's some recent ones I'm remembering:

SSL listening doesn't work in console apps.

There was an SMTP socket bug where STARTTLS negotiation didn't work making it unreliable because many SMTP servers use it.

There have been different memory leaks which probably are now fixed but I don't remember how long they took to fix.

There was a recent HTTP socket bug that didn't allow it to work under certain conditions. It might of been that it didn't correctly handle HTTP 1.1 protocol.

I seem to remember a WE socket bug that prevents WE from working correctly which is another reason I haven't taken time to develop projects in WE.

Search the forum and search the mailing list and you should see.Many customers left the product or stopped using sockets. Many others stopped bug reporting and posting cause it often doesn't fix the problem.

Daniel you claim there are no RS socket bugs, I ask you to prove it.Create one project that tests the different sockets and for the different OSes.Take a couple months if you need to. I bet you cannot find a single version of REAL Studio that works correctly for each socket.

Over the years I've used the SMTP, POP3, TCP, EASYTCP, HTTP, HTTPS, SSL, Serversocket, UDPsocket and even the IPC socket.

Have you?

Last edited by J.Sh3ppard on Mon May 13, 2013 2:13 pm, edited 1 time in total.

Sockets are not broken in RS. I can't rule out that you've found some bug, but I've been using sockets in high performance apps for years.

I'm busy working on my web work right now but I just wanted to reply to this one part of your post in this moment.

So you wanted to waste time bashing RB instead of uploading your test projects...server and client...to a public location so people here can help. Why? How long did it take to complain? How long would it have taken to zip and upload your files?

Sockets are not broken in RS. I can't rule out that you've found some bug, but I've been using sockets in high performance apps for years.

I'm busy working on my web work right now but I just wanted to reply to this one part of your post in this moment.

So you wanted to waste time bashing RB instead of uploading your test projects...server and client...to a public location so people here can help. Why? How long did it take to complain? How long would it have taken to zip and upload your files?

It's not wasting time and it's incredibly insulting for someone else to make unrealistic claims as you did stating "Sockets are not broken in RS.".

Telling the truth about the product and voicing one's accurate concerns is not RB bashing.

Here's a short list from memory about the recent customers that have had similar socket / serious bug complaints, many of which left the product or are about to. Some have even mentioned filing lawsuits because of the false advertising due to the broken features.

Pony, msssltd, Pregan(Phillip Regan), and Nextloop (Matt).

Some of them are IT professionals. Others have professional products they sell to the public. There are many more customers that go with that list but I don't have time to recall them or search the forum.

I have not posted my project yet because I have to clean it up and get rid of un-needed things which may confuse testers.

I'm also about to walk out the door and now I'm running late, thanks.

For some reason a few of you customers like to make false claims about this product. I really don't know why.

I would like to see you people back up your claims of RS being bug free or not suffering serious bugs but you never do.

I suspect some of them make these claims because they get hired to do consulting work using REAL Studio so it's in their favor to makeup stories about it being bug free and reliable.

I have not posted my project yet because I have to clean it up and get rid of un-needed things which may confuse testers.

Please let us know when it's ready.

Quote:

I would like to see you people back up your claims of RS being bug free or not suffering serious bugs but you never do.

Nobody has ever made that claim. There is no software project on Earth with a size and scope comparable to RB that is free of bugs or even free of "serious" bugs. Not one. Not even stuff as critical as flight control software for a fighter jet. The space shuttle retired with bugs still in its software. If that's what you want or expect, then you are in the wrong field. Cocoa, .NET, Java, PHP, JavaScript...they all have bug loads comparable to RB.

Do RB sockets have bugs? I'm sure they do. So do the underlying sockets in Mac OS X, Windows, and Linux. Are they "broken", i.e. unusable for writing a server app? Any public facing WE app on the planet is sufficient to disprove that claim.

Activity monitor shows the app was hitting 90% to 100% when sending and receiving the connections. I will later test the CPU suckdown for only receiving then sending back a simple reply to the client mimicking a real world scenario.

I have further testing to do and I expect the serversocket's CPU suckdown will lessen a little because right now I'm using the app to both accept and connect so part of the suckdown is the connecting process which would not be present on an actual server. I believe it's about 20% so the real serversocket suckdown would be about 70% to 80% which is not acceptable.

For comparison I ran Apache and had php spit out the same reply and it's CPU load was 3%. Huge difference.

Btw, another bug. Possibly mine but possibly REAL Studio's / XOJO's.

For some reason the app is crashing every time after 1,564 connect/disconnects using RS 2010 5.1. As I've written before it won't even connect two times using RS 2012 and it crashes.

I will still probably post this test project after more testing if others want to see if it's my bugs or RS bugs but this is wasting a lot of my time now and I have to get back to making progress using CSS and php on my website.

With as much CPU wasting as the serversocket uses I cannot use it for the project I'm going to develop. It makes no sense. It is too resource hungry.

Activity monitor shows the app was hitting 90% to 100% when sending and receiving the connections. I will later test the CPU suckdown for only receiving then sending back a simple reply to the client mimicking a real world scenario.

Using Apache AB to test the simple web server example that comes with RB I'm having a difficult time getting it to break 2% CPU activity even with high concurrency settings. Of course it's not really doing anything other then transmitting a tiny bit of text. But that's a far cry from the claim of 90-100% just opening connections.

I've also never seen any evidence of high CPU use just to receive incoming connections in the apps I have in the wild.

Unless the ServerSocket class has been reworked since 2011R4.3, I would say it is your code sucking the CPU. I think you said you were writing a console app. If that is the case, you must remember to cooperate with the framework, as you don't have a window message loop to fall back on.

Quote:

Activity monitor shows the app was hitting 90% to 100% when sending and receiving the connections.

With a non-secure socket server, when a connection is established, you might see a brief spike in CPU. Any more than that, you need to review your code. I haven't tested secure sockets though.

Quote:

For comparison I ran Apache and had php spit out the same reply and it's CPU load was 3%. Huge difference.

There is no meaningful comparison to be made. Apache is written is C and uses pre-emptive threading, where it can. If what you are trying to write is some highly concurrent, real time application server, RS would be the wrong tool. PHP would be too.

Quote:

For some reason the app is crashing every time after 1,564 connect/disconnects using RS 2010 5.1. As I've written before it won't even connect two times using RS 2012 and it crashes.

If you are still recycling sockets without closing them, I am not really surprised. Remember networks use protocols. Both ends must behave exactly within the agreed manner. When you digress from the protocol, strange things may happen. It would not surprise me to find you are picking up references to sockets in time_wait.

Quote:

With as much CPU wasting as the serversocket uses I cannot use it for the project I'm going to develop. It makes no sense. It is too resource hungry.

The server socket does very little. It maintains a pool of listening sockets and hands them off to your application code, when they become connected, is about all.

As I said, I don't have a great deal of experience with SecureSocket but I use the ServerSocket a lot, almost exclusively in console applications. I would not call RS sockets fast but they are functional. The applications are hardly light weight either, by the time the framework is loaded. Still much less RAM than a GUI occupies though. I avoid making synchronous calls like the plague, because they will suck the CPU. Apart from that, let the framework breathe, don't spend too long in a DataAvailable event and remember it is reentrant. When my call chains start getting too long, I refactor in an event queue thread and just post a message from DataAvailable.

And if the app compiles and launches without a bus error, jobs a good un.