www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Simplified socket creation and handling

reply "Jarl =?UTF-8?B?QW5kcsOp?= " <jarl.andre gmail.com> writes:
I am a Java developer who is tired of java.nio and similar 
complex socket libraries.

In Java you got QuickServer, the ultimate protocol creation 
centered socket library. You don't have to write any channels and 
readers and what not. You just instantiate a server, configures 
the handlers (fill in classes that extends a handler interface) 
and there you go.

Shouldn't there exist a similar library in any programming 
language? Not doing so is assuming that developers always need 
control of the lower layers. Its not true. I care about protocol. 
Not sockets.

Is there any abstraction layers in phobos? Or is everything just 
as complex as before?
May 17 2012
next sibling parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a handler 
 interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always need 
 control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


Check out arsd:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

I used cgi.d to make my own server easily (compile with 
-version=embedded_httpd). If you want more lower-level control, 
try a ListeningConnectionManager. To see how it's used, look at 


It has some pitfalls (e.g. I can't find a good way to stop the 
server), but it is very nice in _easily_ starting up, with _zero_ 
config.

NMS
May 19 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 It has some pitfalls (e.g. I can't find a good way to stop the 
 server)


When I use it, I just leave it open in a terminal window.
Control+C can then kill it. (I'm on linux but I think the
same would apply on Windows.)

That's the only way right now. I was trying to make break;
work in that connect opApply thing, but it didn't work
right so there is no quit ability inside the app right now.
May 21 2012
parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 It has some pitfalls (e.g. I can't find a good way to stop the 
 server)


 When I use it, I just leave it open in a terminal window.
 Control+C can then kill it. (I'm on linux but I think the
 same would apply on Windows.)

 That's the only way right now. I was trying to make break;
 work in that connect opApply thing, but it didn't work
 right so there is no quit ability inside the app right now.


That's what I've done too, though it fails to call destructors.

I tried manager.quit(), but it results in segfaults for some 
reason (I think it has something to do with background threads).
May 21 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:

 On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 It has some pitfalls (e.g. I can't find a good way to stop 
 the server)


 When I use it, I just leave it open in a terminal window.
 Control+C can then kill it. (I'm on linux but I think the
 same would apply on Windows.)

 That's the only way right now. I was trying to make break;
 work in that connect opApply thing, but it didn't work
 right so there is no quit ability inside the app right now.


 That's what I've done too, though it fails to call destructors.

 I tried manager.quit(), but it results in segfaults for some 
 reason (I think it has something to do with background threads).


Now I have removed the code that rendered the server incomatible 
with windows. Now documentation is the biggest todo on my list. 
Also notice I have added a bat script for running the 
simpleserver :)
May 30 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Wednesday, 30 May 2012 at 20:09:43 UTC, Jarl André wrote:

 On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:

 On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 
 wrote:

 It has some pitfalls (e.g. I can't find a good way to stop 
 the server)


 When I use it, I just leave it open in a terminal window.
 Control+C can then kill it. (I'm on linux but I think the
 same would apply on Windows.)

 That's the only way right now. I was trying to make break;
 work in that connect opApply thing, but it didn't work
 right so there is no quit ability inside the app right now.


 That's what I've done too, though it fails to call destructors.

 I tried manager.quit(), but it results in segfaults for some 
 reason (I think it has something to do with background 
 threads).


 Now I have removed the code that rendered the server 
 incomatible with windows. Now documentation is the biggest todo 
 on my list. Also notice I have added a bat script for running 
 the simpleserver :)


I replied to the wrong author but anyway, if anyone wants to 
contribute to this project just tell me. Cheers.
May 30 2012
next sibling parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
Now the similarity to the original quickserver library in java is 
so ripped off that I had an email sent over to the author asking 
for permission to continue on the api clone or alternatively 
change the api. Comments or suggestions? sucks totally or worth a 
penny?
Jun 02 2012
prev sibling parent reply "Donald Duvall" <don.duvall deduvall.com> writes:
On Wednesday, 30 May 2012 at 20:12:07 UTC, Jarl André wrote:

 On Wednesday, 30 May 2012 at 20:09:43 UTC, Jarl André wrote:

 On Monday, 21 May 2012 at 19:06:24 UTC, Nathan M. Swan wrote:

 On Monday, 21 May 2012 at 17:54:56 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 
 wrote:

 It has some pitfalls (e.g. I can't find a good way to stop 
 the server)


 When I use it, I just leave it open in a terminal window.
 Control+C can then kill it. (I'm on linux but I think the
 same would apply on Windows.)

 That's the only way right now. I was trying to make break;
 work in that connect opApply thing, but it didn't work
 right so there is no quit ability inside the app right now.


 That's what I've done too, though it fails to call 
 destructors.

 I tried manager.quit(), but it results in segfaults for some 
 reason (I think it has something to do with background 
 threads).


 Now I have removed the code that rendered the server 
 incomatible with windows. Now documentation is the biggest 
 todo on my list. Also notice I have added a bat script for 
 running the simpleserver :)


 I replied to the wrong author but anyway, if anyone wants to 
 contribute to this project just tell me. Cheers.


Thank you for the Windows compatibility. I will try it out ASAP.
Jun 04 2012
parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
 Thank you for the Windows compatibility. I will try it out ASAP.


I have now added some subtle changes to the server and example 
echo server. I have added an example for how byte streams can be 
passed to the server by converting them to base64. In my example 
the base64 encoded data is appended to a command. In this way I 
do not have to think about support for reading and writing bytes 
to and from sockets. Its a pain so I am trying to find a way to 
simplify this communication. I may incorporate this base64 
encode/decode into the server library, but at this point 
everything is in the echoserver.d file, visible for the naked eye 
:)

Question about Base64.decode(chomped)

Why is it possible to decode a string like "ddd"? I thought 
base64 was a strict format? I would like any encoder/decoder to 
throw exception on error not just returning whatever that was 
passed to the function.
Jun 05 2012
prev sibling parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a 
 handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always need 
 control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 Check out arsd:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 I used cgi.d to make my own server easily (compile with 
 -version=embedded_httpd). If you want more lower-level control, 
 try a ListeningConnectionManager. To see how it's used, look at 


 It has some pitfalls (e.g. I can't find a good way to stop the 
 server), but it is very nice in _easily_ starting up, with 
 _zero_ config.

 NMS


Thanks. It looks like a good option.

As it turns out I am very interested in having complete control 
of what type of service I am creating, so a library limiting me 
in some ways are not an option. On the other hand, I have 
investigated the listener example and have found out that I 
needed to generalize it a bit. Make a few interfaces, some 
implementations and my initial goal is to have end user code look 
excactly like QuickServers in Java. Why? Because sometimes you 
need simple command servers, lets say for polling an email or 
checking hardware status on a server and report it back, not 
worrying about blocking and async or whatever about sockets.

Another great advantage of making a "QuickServer" library is that 
its inner content can be replaced in the future without the end 
users knowing about. I have come far in the library making, but 
need some help understanding std.socket:

1.a. What is SocketSet and why do I need to pass it to 
Socket.select?
1.b. I only want to accept new sockets and I think its too much 
code for that

Even if questions is stupid please comment/correct me.
May 23 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a 
 handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always 
 need control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 Check out arsd:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 I used cgi.d to make my own server easily (compile with 
 -version=embedded_httpd). If you want more lower-level 
 control, try a ListeningConnectionManager. To see how it's 


 It has some pitfalls (e.g. I can't find a good way to stop the 
 server), but it is very nice in _easily_ starting up, with 
 _zero_ config.

 NMS


 Thanks. It looks like a good option.

 As it turns out I am very interested in having complete control 
 of what type of service I am creating, so a library limiting me 
 in some ways are not an option. On the other hand, I have 
 investigated the listener example and have found out that I 
 needed to generalize it a bit. Make a few interfaces, some 
 implementations and my initial goal is to have end user code 
 look excactly like QuickServers in Java. Why? Because sometimes 
 you need simple command servers, lets say for polling an email 
 or checking hardware status on a server and report it back, not 
 worrying about blocking and async or whatever about sockets.

 Another great advantage of making a "QuickServer" library is 
 that its inner content can be replaced in the future without 
 the end users knowing about. I have come far in the library 
 making, but need some help understanding std.socket:

 1.a. What is SocketSet and why do I need to pass it to 
 Socket.select?
 1.b. I only want to accept new sockets and I think its too much 
 code for that

 Even if questions is stupid please comment/correct me.


And here it comes:

https://github.com/jarlah/d2-simple-socket-server

This is my object oriented contribution to the problem.

Based on closed/open principe, in that expansion is done by 
adding new classes and not modifying the existing code.

Comments are appreciated.
May 23 2012
parent reply "Donald Duvall" <don.duvall deduvall.com> writes:
On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:

 On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any 
 channels and readers and what not. You just instantiate a 
 server, configures the handlers (fill in classes that 
 extends a handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always 
 need control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 Check out arsd:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 I used cgi.d to make my own server easily (compile with 
 -version=embedded_httpd). If you want more lower-level 
 control, try a ListeningConnectionManager. To see how it's 


 It has some pitfalls (e.g. I can't find a good way to stop 
 the server), but it is very nice in _easily_ starting up, 
 with _zero_ config.

 NMS


 Thanks. It looks like a good option.

 As it turns out I am very interested in having complete 
 control of what type of service I am creating, so a library 
 limiting me in some ways are not an option. On the other hand, 
 I have investigated the listener example and have found out 
 that I needed to generalize it a bit. Make a few interfaces, 
 some implementations and my initial goal is to have end user 
 code look excactly like QuickServers in Java. Why? Because 
 sometimes you need simple command servers, lets say for 
 polling an email or checking hardware status on a server and 
 report it back, not worrying about blocking and async or 
 whatever about sockets.

 Another great advantage of making a "QuickServer" library is 
 that its inner content can be replaced in the future without 
 the end users knowing about. I have come far in the library 
 making, but need some help understanding std.socket:

 1.a. What is SocketSet and why do I need to pass it to 
 Socket.select?
 1.b. I only want to accept new sockets and I think its too 
 much code for that

 Even if questions is stupid please comment/correct me.


 And here it comes:

 https://github.com/jarlah/d2-simple-socket-server

 This is my object oriented contribution to the problem.

 Based on closed/open principe, in that expansion is done by 
 adding new classes and not modifying the existing code.

 Comments are appreciated.


Would it be possible for someone to write some documentation on 
this socket server and make it windows compatible?


different and I understand it completely. I would much appreciate 
any help with understanding sockets in D and any pointers in the 
right direction.
May 25 2012
parent reply "Donald Duvall" <don.duvall deduvall.com> writes:
On Friday, 25 May 2012 at 20:50:25 UTC, Donald Duvall wrote:

 On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:

 On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 
 wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any 
 channels and readers and what not. You just instantiate a 
 server, configures the handlers (fill in classes that 
 extends a handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always 
 need control of the lower layers. Its not true. I care 
 about protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 Check out arsd:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 I used cgi.d to make my own server easily (compile with 
 -version=embedded_httpd). If you want more lower-level 
 control, try a ListeningConnectionManager. To see how it's 


 It has some pitfalls (e.g. I can't find a good way to stop 
 the server), but it is very nice in _easily_ starting up, 
 with _zero_ config.

 NMS


 Thanks. It looks like a good option.

 As it turns out I am very interested in having complete 
 control of what type of service I am creating, so a library 
 limiting me in some ways are not an option. On the other 
 hand, I have investigated the listener example and have found 
 out that I needed to generalize it a bit. Make a few 
 interfaces, some implementations and my initial goal is to 
 have end user code look excactly like QuickServers in Java. 
 Why? Because sometimes you need simple command servers, lets 
 say for polling an email or checking hardware status on a 
 server and report it back, not worrying about blocking and 
 async or whatever about sockets.

 Another great advantage of making a "QuickServer" library is 
 that its inner content can be replaced in the future without 
 the end users knowing about. I have come far in the library 
 making, but need some help understanding std.socket:

 1.a. What is SocketSet and why do I need to pass it to 
 Socket.select?
 1.b. I only want to accept new sockets and I think its too 
 much code for that

 Even if questions is stupid please comment/correct me.


 And here it comes:

 https://github.com/jarlah/d2-simple-socket-server

 This is my object oriented contribution to the problem.

 Based on closed/open principe, in that expansion is done by 
 adding new classes and not modifying the existing code.

 Comments are appreciated.


 Would it be possible for someone to write some documentation on 
 this socket server and make it windows compatible?


 different and I understand it completely. I would much 
 appreciate any help with understanding sockets in D and any 
 pointers in the right direction.


Sorry for the typo: I do NOT understand it completely.
May 25 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Friday, 25 May 2012 at 20:55:12 UTC, Donald Duvall wrote:

 On Friday, 25 May 2012 at 20:50:25 UTC, Donald Duvall wrote:

 On Wednesday, 23 May 2012 at 19:24:53 UTC, Jarl André wrote:

 On Wednesday, 23 May 2012 at 13:39:09 UTC, Jarl André wrote:

 On Saturday, 19 May 2012 at 20:33:49 UTC, Nathan M. Swan 
 wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol 
 creation centered socket library. You don't have to write 
 any channels and readers and what not. You just 
 instantiate a server, configures the handlers (fill in 
 classes that extends a handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always 
 need control of the lower layers. Its not true. I care 
 about protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is 
 everything just as complex as before?


 Check out arsd:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 I used cgi.d to make my own server easily (compile with 
 -version=embedded_httpd). If you want more lower-level 
 control, try a ListeningConnectionManager. To see how it's 


 It has some pitfalls (e.g. I can't find a good way to stop 
 the server), but it is very nice in _easily_ starting up, 
 with _zero_ config.

 NMS


 Thanks. It looks like a good option.

 As it turns out I am very interested in having complete 
 control of what type of service I am creating, so a library 
 limiting me in some ways are not an option. On the other 
 hand, I have investigated the listener example and have 
 found out that I needed to generalize it a bit. Make a few 
 interfaces, some implementations and my initial goal is to 
 have end user code look excactly like QuickServers in Java. 
 Why? Because sometimes you need simple command servers, lets 
 say for polling an email or checking hardware status on a 
 server and report it back, not worrying about blocking and 
 async or whatever about sockets.

 Another great advantage of making a "QuickServer" library is 
 that its inner content can be replaced in the future without 
 the end users knowing about. I have come far in the library 
 making, but need some help understanding std.socket:

 1.a. What is SocketSet and why do I need to pass it to 
 Socket.select?
 1.b. I only want to accept new sockets and I think its too 
 much code for that

 Even if questions is stupid please comment/correct me.


 And here it comes:

 https://github.com/jarlah/d2-simple-socket-server

 This is my object oriented contribution to the problem.

 Based on closed/open principe, in that expansion is done by 
 adding new classes and not modifying the existing code.

 Comments are appreciated.


 Would it be possible for someone to write some documentation 
 on this socket server and make it windows compatible?


 different and I understand it completely. I would much 
 appreciate any help with understanding sockets in D and any 
 pointers in the right direction.


 Sorry for the typo: I do NOT understand it completely.


Thanks for the feedback! Well, for me I am a Java enterprise 
developer working with Java on Unix, but, I have worked with .NET 
in the past giving me a tiny portion of mercy to those that 
enjoys Visual Studio :) Its actually a blazing fast IDE. Enough 
digression.

The last days I have completely rewritten the library, and have 
also added a build script (you can just rename it from 
"simpleserver.sh" to "simpleserver.bat" and it will work. 
However, there are two things about this library that I am 
currently working on:

1. Windows support is lacking because I use a thread pool with 
imports for posix (unix systems) and I'm not extremely good at D 
yet.

2. For some reason I left an implementation of 
AbstractClientCommandHamdler in the quickserver library but it 
was intentional that this should reside in the simpleserver.d 
file, completely closing the library and making it possible to 
create a server without modifying the library at all.

3. I am wondering if I should export the threadpool into its own 
library so not to clutter up the quickserver.d file with 
Windows/Posix compability code. At the moment the server itslf is 
system independent.

So the answer is: yes I'll try to look at windows support, but if 
someone wants to help me I'll gladly say yes.
May 27 2012
parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
 Sorry for the typo: I do NOT understand it completely.


 Thanks for the feedback! Well, for me I am a Java enterprise 
 developer working with Java on Unix, but, I have worked with 
 .NET in the past giving me a tiny portion of mercy to those 
 that enjoys Visual Studio :) Its actually a blazing fast IDE. 
 Enough digression.

 The last days I have completely rewritten the library, and have 
 also added a build script (you can just rename it from 
 "simpleserver.sh" to "simpleserver.bat" and it will work. 
 However, there are two things about this library that I am 
 currently working on:

 1. Windows support is lacking because I use a thread pool with 
 imports for posix (unix systems) and I'm not extremely good at 
 D yet.

 2. For some reason I left an implementation of 
 AbstractClientCommandHamdler in the quickserver library but it 
 was intentional that this should reside in the simpleserver.d 
 file, completely closing the library and making it possible to 
 create a server without modifying the library at all.

 3. I am wondering if I should export the threadpool into its 
 own library so not to clutter up the quickserver.d file with 
 Windows/Posix compability code. At the moment the server itslf 
 is system independent.

 So the answer is: yes I'll try to look at windows support, but 
 if someone wants to help me I'll gladly say yes.


I completed todo 2 and 3. Now lets hope someone wants to 
contribute cross compability code on todo 1. It should be fairly 
easy since the threadpool now resides in its own module file.
May 27 2012
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a handler 
 interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always need 
 control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


I use QuickServer myself, and was thinking about creating 
something like that in D for quite some time...
May 30 2012
next sibling parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Wednesday, 30 May 2012 at 08:40:48 UTC, Dejan Lekic wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a 
 handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always need 
 control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 I use QuickServer myself, and was thinking about creating 
 something like that in D for quite some time...


Good to hear! Your comment sparked the last in me to find out 
what was terribly wrong with my code. Spawning 1000 threads to 
the service never succeded. By investigating and copying from the 
listener example in std.socket library I found out that I had to 
use the SocketSet for all socket connections. In Java I could 
communicate based on a socket connection per client in multiple 
threads. With the berkeley api i am not able to do the same thing 
and it all fails tremendously if i try. Any reason why I cannot 
take a socket and communicate with its receive and send method 
solely?
May 30 2012
prev sibling parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Wednesday, 30 May 2012 at 08:40:48 UTC, Dejan Lekic wrote:

 On Friday, 18 May 2012 at 06:35:59 UTC, Jarl André wrote:

 I am a Java developer who is tired of java.nio and similar 
 complex socket libraries.

 In Java you got QuickServer, the ultimate protocol creation 
 centered socket library. You don't have to write any channels 
 and readers and what not. You just instantiate a server, 
 configures the handlers (fill in classes that extends a 
 handler interface) and there you go.

 Shouldn't there exist a similar library in any programming 
 language? Not doing so is assuming that developers always need 
 control of the lower layers. Its not true. I care about 
 protocol. Not sockets.

 Is there any abstraction layers in phobos? Or is everything 
 just as complex as before?


 I use QuickServer myself, and was thinking about creating 
 something like that in D for quite some time...


Btw I updated my github project so now my little "quickserver" is
actually working :)
May 30 2012