Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 1 Jahr, 9 Monaten
Letzter Beitrag:
vor 1 Jahr, 9 Monaten
Beteiligte Autoren:
Stewart Crisler, Danny Lauwers, Stefano Giavardi, Fabrice Harari, DannHCS

[WD20] Socket Server: Desktop VS Service

Startbeitrag von DannHCS am 18.08.2016 10:34


I develop a Socket Server working on a service.
It uses many threads to manage the differents connections of mobile devices.

During the "crash" tests by sending a lot of strings simultaneously sometimes I reach a "dead end" where:

- Socket Server is ON, because the SocketConnect on the mobile devices gives a positive result
- SocketRead and SocketWrite don't work on the Server
- service is interrupted
- the window, built for the setup of the service, crashes when I try to uninstall the service
- all the connections of devices hang on the PC

I tried to develop the same Server on a Window, in which a thread works as the loop of the service above.

The difference: IT NEVER REACH A "DEAD END"

What is the reason of this difference?
Do the threads or socket work differently on service and on desktop?



Hi Dann,

EVERYTHING works differently (or can work differently) in a service, because the user under which the service run has a set of permissions very different than a regular user.

So the first thing to do is to do in your service settings and change the user running it ofr your regular login (the one you are using for the desktop version)

If in that configuration everything works well, then you know its a permission problem, and either you leave it like that, or you look for the instruction that was blocking you and change it for something else.

Best regards

von Fabrice Harari - am 18.08.2016 11:20
I have to write something similar in near future for managing handheld wifi radio frequency devices with barcode scanner talking with a server pc where the DB is located.

In general I'm a little curious about similar experiences and "success stories" (running stable) on your actual customers by people on this forum. Just to be prepared about "What Not To Do" in advance and save time skipping common errors.

For example...
Is there a reason to prefer a Windows App instead of a Service for Server-Side?
How many of you had issues like Dann and how many solved them?
Is there a limit to sudden cuncurrence supported by a WD socket server?
If I want a service, do I have to set up some trick to make things running steady&smooth?
Is there someone that installed this technology and have actually no problems?
Is there a reason to prefer a Web Service communication instead of WD Sockets?

WD project Examples on sockets are unlucky. I know that sometimes WD has issues but I also have confidence in the common saying "I always found in WD a workaround to bypass any empass/lock".
My goal now is not having a tutorial of how to do (if I can't do I will pay someone to train or help me), I would like to know if all this is 100% feasible with a simple socket technology (as I did many years ago in Java) or in WD I will cry :)


von Stefano Giavardi - am 18.08.2016 11:44

Just informational, we have implemented a MQTT ( http://mqtt.org/ , its a standard) between Android (WinDev Mobile) and a .NET program.

The MQTT is a protocol for connecting sensors or small devices to a broker and handle the communications. It is very robust written.It is available in a lot of languages (excepts WL), so you can run it on Rasberry Pi, Arduino, Linux (Python), Windows,...

I do not have a WLanguage version (Yet), but it could be possible to use the .NET version in your WinDev Programs.

Instead of writing the full communication stack, using the MQTT handles that, and all you need to do in your devices is to subscribe to a certain queue name to get messages, and to send stuff is do write to a certain name queue. The rest is done by the underlying MQTT protocol.

It is open source, but if you have to write this in WLanguage, than it would be some work interpreting the C or C++, Java, or other language version to get it to WLanguage.

In the core it is just TCP communication, so it should be possible to write a native WLanguage MQTT implementation.

This just as info, but there are a lot of interesting things in this protocol that would also be interesting if you would write your own communications protocol anyway.

A lot of info is also available here, in the blog and links:


MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.
Who invented MQTT?
MQTT was invented by Dr Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech), in 1999.


von Danny Lauwers - am 18.08.2016 15:46
If you are going to consider message queues, you might want to look at ZeroMQ. Somebody did the C bindings for ZeroMQ and they were on the PCSoft web site somewhere.

I developed a service that implemented http in a limited way as a faux web server. It is rock stable.

My general experience with WinDev is that once you get it worked out, it is rock stable.

Beyond the security concerns mentioned, you have to write a service as a service and pay attention to what is allowed which can be different compared to a regular Windows program.

Stewart Crisler

von Stewart Crisler - am 18.08.2016 18:19
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.