Pure basic for DLL programming that will do Socket comm.
Pure basic for DLL programming that will do Socket comm.
Hi,
We are considering to buy Pure Basic.
We have to develop a windows DLL that will be called by other applications.
The DLL has to do socket communication with a central server.
The goal of the DLL is to hide the actual burden of doing the socket communication to other programmers and reduce the problem for them to a simple call of a couple of functions of a DLL.
Can this DLL developpement be done in Purebasic ?
Rony
We are considering to buy Pure Basic.
We have to develop a windows DLL that will be called by other applications.
The DLL has to do socket communication with a central server.
The goal of the DLL is to hide the actual burden of doing the socket communication to other programmers and reduce the problem for them to a simple call of a couple of functions of a DLL.
Can this DLL developpement be done in Purebasic ?
Rony
Hi,
I've delayed responding, hoping that someone with more networking experience than myself would wander along and answer your question. I'm sure one of the networking gurus will pop their head in sooner or later!
Personally I cannot see that you will have a problem in using Purebasic to create your dll. PB has a nice network library which is really quite simple to use and creating dll's is a breeze in PB.
I've delayed responding, hoping that someone with more networking experience than myself would wander along and answer your question. I'm sure one of the networking gurus will pop their head in sooner or later!

Personally I cannot see that you will have a problem in using Purebasic to create your dll. PB has a nice network library which is really quite simple to use and creating dll's is a breeze in PB.
I may look like a mule, but I'm not a complete ass.
It sounds like you have a project coming already. Are there any other requirements? Are the connecting apps looking for "normal" DLLs or more of the activex variety?
Some of that COM / ActiveX stuff could really be a complicated task in PB. If it's a standard win32 DLL with an API you want to pubish ( as apposed to an object model) then PB is the way to go.
Is the central server already existing and with a specific protocol or will this all be under your control too?
Some of that COM / ActiveX stuff could really be a complicated task in PB. If it's a standard win32 DLL with an API you want to pubish ( as apposed to an object model) then PB is the way to go.
Is the central server already existing and with a specific protocol or will this all be under your control too?
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Thanks for your answer.
It will be a standard win32 DLL with a published API.
The server is allso a developpement by us, protocol is defined by us, communication layer is win socket over TCP/IP.
The reason that we have to develop this dll is that other applications (not developped by us) have to communicate with the server, and we have the experience that a lot of developpers have no experience with TCP communication. But every developper can call a Dll, right
Rony
It will be a standard win32 DLL with a published API.
The server is allso a developpement by us, protocol is defined by us, communication layer is win socket over TCP/IP.
The reason that we have to develop this dll is that other applications (not developped by us) have to communicate with the server, and we have the experience that a lot of developpers have no experience with TCP communication. But every developper can call a Dll, right

Rony
pdwyer wrote:It sounds like you have a project coming already. Are there any other requirements? Are the connecting apps looking for "normal" DLLs or more of the activex variety?
Some of that COM / ActiveX stuff could really be a complicated task in PB. If it's a standard win32 DLL with an API you want to pubish ( as apposed to an object model) then PB is the way to go.
Is the central server already existing and with a specific protocol or will this all be under your control too?
Sounds like you shouldn't have a problem then 
Is there are reason why you are not coding it in the same language you did for the server? Was it on solaris or HPUX or something and only the client will be windows?
Good idea about controlling the communications, developers will probably still find ways to accidently DOS your server though but it leaves you with some control

Is there are reason why you are not coding it in the same language you did for the server? Was it on solaris or HPUX or something and only the client will be windows?
Good idea about controlling the communications, developers will probably still find ways to accidently DOS your server though but it leaves you with some control

Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Yes there is a reason, our 'normal' developpement environment is WINDEV from Pcsoft
But Windev can't create DLL's....
Another solution would be C/C++ but at first sight, from reading the documentation on the site, it looks simpler to do it in Pure Basic
Rony
But Windev can't create DLL's....
Another solution would be C/C++ but at first sight, from reading the documentation on the site, it looks simpler to do it in Pure Basic
Rony
pdwyer wrote:Sounds like you shouldn't have a problem then
Is there are reason why you are not coding it in the same language you did for the server? Was it on solaris or HPUX or something and only the client will be windows?
Good idea about controlling the communications, developers will probably still find ways to accidently DOS your server though but it leaves you with some control
-
- New User
- Posts: 2
- Joined: Sun May 07, 2006 11:01 pm
Dear bucodi,
I do not see why it should be easier to create a DLL with PureBasic instead of using VisualC++.
However. I do not know what you are planning, but let me write down the experience I had with PB (v3.94 & tried v4.00 later) writing a WinSock2 based server.
Using the PB Network Library you have control over nothing! It is just impossible to write a reliable & scalable server with this Lib!
This will lead to importing the WinSock functions, structures into PB etc. --> so why wasting time for this, if they are just directly accessible with C++???
I have managed to write a select()-based server with PB and it was running well, until I made a real test-drive - only to see, that the software just broke down after several seconds of accept()-ing more than 100 concurrent connections.
Exactly the same code in C++ (VisualC++) was working like a charm - rock solid.
Because I never give up and I like(d) PB way to much I tried the following:
I created a DLL with VisualC++ containing the entire server code and made accessible only four functions something like: Init(), Start(), End(), CleanUp(). I called the DLL with PureBasic and what happened?? The same thing I experienced with the PB-version of the server. It just could not manage more than some 100 concurrent connections/sec for a limited time.
Nota bene, it the last case PB was only calling the functions/procedures from the DLL (which was written in C++) and there was no code written in PB that could lead to an error.
You may say, that there could be some error in my code, but the server I have writte (I gave up PB in this special case and made it in C++) is in productional use already for more than one year, and it has never crashed or caused any failure. It accepts up to 4000 concurrent connections and is one of the most reliable software I have ever written.
----------------------------
I also tested several examples that users have posted to this forum, among them a highly praised webserver & messenger server/client software. When I put these server under heavy attack, they even did not manage to survive some seconds! It is to be noted, that the guys used the PB Network Lib for these experiments.
This strange behaviour leads to the conclusion, that there must have been some serious issues with the above mentions versions of PureBasic or some PB Libs or what ever.
----------------------------
C++ is the one and only language on earth that is capable of creating reliable and even more important scaleable network server/client software and gives you the liberty a coder is dreaming of.
----------------------------
Things may have change with PB 4.2 but this is to be proved - so I cannot say anything about this.
----------------------------
However just a small info. There are several models for network server software available:
- select() -based
- WSAAsyncSelect - based
- WSAEventSelect - based
- overlapped IO - based
- completion ports - based one using overlapped I/O
The select()-based blocking model is the "easiest" one. The select-()-based non-blocking is the next step to more concurrent connections but there are also some issues to be solved with the CPU load.
The IOCP (IO completion ports) is the most scaleable and also the most difficult one, and you will not find much information about them - and if, they will not work as expected. But there are several books around there, so get one, get your time to get used to C++ and you will be happy!
----------------------------
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."
++Bjarne Stroustrup
----------------------------
I hope this could be of any help.
cu
Martin
I do not see why it should be easier to create a DLL with PureBasic instead of using VisualC++.
However. I do not know what you are planning, but let me write down the experience I had with PB (v3.94 & tried v4.00 later) writing a WinSock2 based server.
Using the PB Network Library you have control over nothing! It is just impossible to write a reliable & scalable server with this Lib!
This will lead to importing the WinSock functions, structures into PB etc. --> so why wasting time for this, if they are just directly accessible with C++???
I have managed to write a select()-based server with PB and it was running well, until I made a real test-drive - only to see, that the software just broke down after several seconds of accept()-ing more than 100 concurrent connections.
Exactly the same code in C++ (VisualC++) was working like a charm - rock solid.
Because I never give up and I like(d) PB way to much I tried the following:
I created a DLL with VisualC++ containing the entire server code and made accessible only four functions something like: Init(), Start(), End(), CleanUp(). I called the DLL with PureBasic and what happened?? The same thing I experienced with the PB-version of the server. It just could not manage more than some 100 concurrent connections/sec for a limited time.
Nota bene, it the last case PB was only calling the functions/procedures from the DLL (which was written in C++) and there was no code written in PB that could lead to an error.
You may say, that there could be some error in my code, but the server I have writte (I gave up PB in this special case and made it in C++) is in productional use already for more than one year, and it has never crashed or caused any failure. It accepts up to 4000 concurrent connections and is one of the most reliable software I have ever written.
----------------------------
I also tested several examples that users have posted to this forum, among them a highly praised webserver & messenger server/client software. When I put these server under heavy attack, they even did not manage to survive some seconds! It is to be noted, that the guys used the PB Network Lib for these experiments.
This strange behaviour leads to the conclusion, that there must have been some serious issues with the above mentions versions of PureBasic or some PB Libs or what ever.
----------------------------
C++ is the one and only language on earth that is capable of creating reliable and even more important scaleable network server/client software and gives you the liberty a coder is dreaming of.
----------------------------
Things may have change with PB 4.2 but this is to be proved - so I cannot say anything about this.
----------------------------
However just a small info. There are several models for network server software available:
- select() -based
- WSAAsyncSelect - based
- WSAEventSelect - based
- overlapped IO - based
- completion ports - based one using overlapped I/O
The select()-based blocking model is the "easiest" one. The select-()-based non-blocking is the next step to more concurrent connections but there are also some issues to be solved with the CPU load.
The IOCP (IO completion ports) is the most scaleable and also the most difficult one, and you will not find much information about them - and if, they will not work as expected. But there are several books around there, so get one, get your time to get used to C++ and you will be happy!
----------------------------
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."
++Bjarne Stroustrup
----------------------------
I hope this could be of any help.
cu
Martin
HUH? I have never had any of the problems you are claiming to have with the PB network library...zenoncount wrote:Dear bucodi,
I do not see why it should be easier to create a DLL with PureBasic instead of using VisualC++.
However. I do not know what you are planning, but let me write down the experience I had with PB (v3.94 & tried v4.00 later) writing a WinSock2 based server.
Using the PB Network Library you have control over nothing! It is just impossible to write a reliable & scalable server with this Lib!
This will lead to importing the WinSock functions, structures into PB etc. --> so why wasting time for this, if they are just directly accessible with C++???
I have managed to write a select()-based server with PB and it was running well, until I made a real test-drive - only to see, that the software just broke down after several seconds of accept()-ing more than 100 concurrent connections.
Exactly the same code in C++ (VisualC++) was working like a charm - rock solid.
Because I never give up and I like(d) PB way to much I tried the following:
I created a DLL with VisualC++ containing the entire server code and made accessible only four functions something like: Init(), Start(), End(), CleanUp(). I called the DLL with PureBasic and what happened?? The same thing I experienced with the PB-version of the server. It just could not manage more than some 100 concurrent connections/sec for a limited time.
Nota bene, it the last case PB was only calling the functions/procedures from the DLL (which was written in C++) and there was no code written in PB that could lead to an error.
You may say, that there could be some error in my code, but the server I have writte (I gave up PB in this special case and made it in C++) is in productional use already for more than one year, and it has never crashed or caused any failure. It accepts up to 4000 concurrent connections and is one of the most reliable software I have ever written.
----------------------------
I also tested several examples that users have posted to this forum, among them a highly praised webserver & messenger server/client software. When I put these server under heavy attack, they even did not manage to survive some seconds! It is to be noted, that the guys used the PB Network Lib for these experiments.
This strange behaviour leads to the conclusion, that there must have been some serious issues with the above mentions versions of PureBasic or some PB Libs or what ever.
----------------------------
C++ is the one and only language on earth that is capable of creating reliable and even more important scaleable network server/client software and gives you the liberty a coder is dreaming of.
----------------------------
Things may have change with PB 4.2 but this is to be proved - so I cannot say anything about this.
----------------------------
However just a small info. There are several models for network server software available:
- select() -based
- WSAAsyncSelect - based
- WSAEventSelect - based
- overlapped IO - based
- completion ports - based one using overlapped I/O
The select()-based blocking model is the "easiest" one. The select-()-based non-blocking is the next step to more concurrent connections but there are also some issues to be solved with the CPU load.
The IOCP (IO completion ports) is the most scaleable and also the most difficult one, and you will not find much information about them - and if, they will not work as expected. But there are several books around there, so get one, get your time to get used to C++ and you will be happy!
----------------------------
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."
++Bjarne Stroustrup
----------------------------
I hope this could be of any help.
cu
Martin
But, he's not writing a server, he's writing a client dll.zenoncount wrote:Using the PB Network Library you have control over nothing! It is just impossible to write a reliable & scalable server with this Lib!
The windows and winsock API is available to PB in the same way it's available to C++, no one is twising their arm to use the a network lib should it not have the functionality they need.
I suppose it comes down to, when he said "PB looks easier" what was he basing this on? Use of the network built in lib? Ease of basic syntax of C++ (for me this is a big one but for some it makes no difference) or something else?
Just because there is a network lib there to make things quicker and easier, doesn't mean that using the API in PB is somehow harder than other languages. Also, if they have $$$ there are cheap third party componants that can be purchase with lots of functionality.
I got the impression they just want to hide the comms and server sync from the average developer by wrapping it up. Can't see the big deal
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
HI, Let me clarify this a bit
We are a very small company (only 4 developpers) and we are writing back office solutions which are deployed all over the world (for those realy interested www.bucodi.com )
The server is a sort of central transaction validation server, it is allready developped and runs allready with severall clients connected.
Until now all clients are software developped by us, so the communication protocol is integrated in our client software.
But...
Recently we had the demand of a company to connect to our server and he has a back software that is not developped by us. On a meeting with there IT provider it appeared that the guys had no knowledge and experience whatsoever about communication...
From there the need for a DLL that they simply can call and fetch the result.
The DLL will actually be quit simple and has only a couple of functions
- Login with fetch of the result
- Logout
- Keep alive message
- Send a message and retrieve the answer. All those message have a fixed format
As you see, it's pretty straightforward, and no multi treading or whatsoever.
Our interest for PB comes from the fact that we have expirience with basic and no experience with C++.
And since we are a small company we can't invest in acquiring the knowledge of C++ (especialy since we don't have the time)
So, is PB the right solution?
Rony
We are a very small company (only 4 developpers) and we are writing back office solutions which are deployed all over the world (for those realy interested www.bucodi.com )
The server is a sort of central transaction validation server, it is allready developped and runs allready with severall clients connected.
Until now all clients are software developped by us, so the communication protocol is integrated in our client software.
But...
Recently we had the demand of a company to connect to our server and he has a back software that is not developped by us. On a meeting with there IT provider it appeared that the guys had no knowledge and experience whatsoever about communication...
From there the need for a DLL that they simply can call and fetch the result.
The DLL will actually be quit simple and has only a couple of functions
- Login with fetch of the result
- Logout
- Keep alive message
- Send a message and retrieve the answer. All those message have a fixed format
As you see, it's pretty straightforward, and no multi treading or whatsoever.
Our interest for PB comes from the fact that we have expirience with basic and no experience with C++.
And since we are a small company we can't invest in acquiring the knowledge of C++ (especialy since we don't have the time)
So, is PB the right solution?
Rony
It sounds like something I started and am still working on - Remote Procedure Calls.
The basic premise is that you call a particular function (from a given dll), and then the dll code does all the hard work of calling the server, executing the function on the server and then returning the result to the client program.
If this is what you are after then I'll have another look at it when I get home, and post what I have. It'll at least give you a head start.
The basic premise is that you call a particular function (from a given dll), and then the dll code does all the hard work of calling the server, executing the function on the server and then returning the result to the client program.
If this is what you are after then I'll have another look at it when I get home, and post what I have. It'll at least give you a head start.
i have exactly done that - even using PBs network lib ( Altho i never tested more than 500 concurrent connections - which ran fine ). Gotta say tho that using teh same code under Linux flys like a jet while under win it kinda snails in ( up to 10 milliseconds delay soemtimes ) - tho i guess this has to do more with the Implementation of Winsock than PB.The DLL will actually be quit simple and has only a couple of functions
- Login with fetch of the result
- Logout
- Keep alive message
- Send a message and retrieve the answer. All those message have a fixed format
Mk-Soft wrote a very nice / simple Server / Client Example which couldbe a nice solid base for what you would like to achieve.
Thalius
"In 3D there is never enough Time to do Things right,
but there's always enough Time to make them *look* right."
"psssst! i steal signatures... don't tell anyone!
"
but there's always enough Time to make them *look* right."
"psssst! i steal signatures... don't tell anyone!

Do you have a link for that? Searching through all his posts on this forum: http://www.purebasic.fr/english/search. ... or=mk-soft , I could not find any results.Thalius wrote: Mk-Soft wrote a very nice / simple Server / Client Example which couldbe a nice solid base for what you would like to achieve.
Thalius
you can find it at his homepage http://home.arcor.de/m_kastner , Meine Projekte, Code Schnipzel, PB4/
My example you has to realize helped the server. There is now a new example as streamserver and block data tranzfer.
http://home.arcor.de/m_kastner/MyCodes/PB4/
GT
http://home.arcor.de/m_kastner/MyCodes/PB4/
GT

My Projects ThreadToGUI / OOP-BaseClass / EventDesigner V3
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive