digitalmars.D.learn - Easy sockets - don't exist yet?
- Vincent (37/37) Sep 26 2016 Hello, guys!
- haxx (10/48) Sep 26 2016 Sockets in D are a thin layer over the BSD sockets, and they do
- Satoshi (15/53) Sep 26 2016 -idiotic "buffers of bytes"!
- Marco Leise (19/27) Sep 27 2016 Haha, this is not how I learned network layers at school.
- Marco Leise (2/2) Sep 27 2016 Just in case, here are the relevant docs:
- Russel Winder via Digitalmars-d-learn (16/63) Sep 27 2016 Why not just create a binding to 0MQ and get much, much more than asked
- JN (6/8) Sep 27 2016 http://code.dlang.org/packages/zmqd
- Russel Winder via Digitalmars-d-learn (14/26) Sep 27 2016 Even better, except it would be good if there was one. Maybe the
- JN (5/22) Sep 27 2016 Not really, because some of these are just pure C bindings, while
- Karabuta (4/13) Oct 08 2016 This is how a usable socket in a standard library should be
- Bauss (3/3) Oct 10 2016 Wrote some pretty simple sockets that you could use (Based on
- Konstantin Kutsevalov (5/8) Oct 10 2016 Hi,
- Vincent (4/6) Dec 03 2022 That's the point! STANDARD library cannot/must not rely on
- Vincent (2/5) Dec 03 2022 Pity, doesn't exist anymore.
- Konstantin Kutsevalov (9/15) Oct 09 2016 Hello, I'm agree with your main question.
- Jonathan M Davis via Digitalmars-d-learn (28/34) Oct 09 2016 Quite some time ago, it was decided that the *stream modules as they wer...
- Konstantin Kutsevalov (3/7) Oct 10 2016 I see, thank you for answer
- Vincent (26/29) Dec 03 2022 That's the key! Absolutely dilettantish solution of "profi",
- Jacob Shtokolov (42/45) Dec 06 2022 A stream is exactly a range, a "range of ranges" if more
- Daniel Kozak via Digitalmars-d-learn (4/19) Oct 09 2016 Until some replacment will occure in phobos socketstream is and will be
Hello, guys!
I was very surprised that module 'socketstream' was deprecated.
Usually if something become obsolete, there is some perfect
replacement! But my digging in Inet and forums gave nothing, but
"outdated" examples with 'SocketStream' class. So first question
is WHAT Phobos has to replace SocketStream?
To avoid unnecessary mail bouncing, I write upfront what I expect
from normal Socket implementation (kind of interface) :
1. Easy to use. No more stupid "UNIX sockets", "TCP types" and so
on. Just simple as this:
// Client side
auto sock = new ClientSocket("google.com", 80);
sock.WriteLine("GET / HTTP/1.0");
sock.WriteLine("Host: google.com");
sock.WriteLine();// empty line sent
// Server side:
auto svc = new ServerSocket("Bound.To.This.IP", 1000);
while ((auto ClientSock = svc.AcceptClient()) !is null) {
auto command = ClientSock.ReadLine();// this is important -
read by line, not idiotic "buffers of bytes"!
ClientSock.WriteLine(command ~ ` yourself!`);
ClientSock.Close();
}
2. Of course integration with std.stream could be nice, it gives
"for free" readLine and other methods.
3. Ability to 'get and forget': hardly all of us wanna deal with
"get portion, write portion to disk, blah". Simple
"sock.ReceiveFile(`http://porno/girl.avi`,
`c:\diploma_work.avi`)" could be enough.
Some kind of "progress report" callback would be nice.
4. SSL/TLS out-of-the-box. In example above it should be same
easy as:
auto sock = new ClientSocket("google.com", 80, Proto.TLS);
At the moment it's all I need, but hope you'll be happy too with
such interface. Sockets are SOOO important, that I cannot believe
we don't have so easy API now. Or if we have, please share!
Thanks everybody!
Sep 26 2016
haxx <skocznymr gmail.com>
On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote:
Hello, guys!
I was very surprised that module 'socketstream' was deprecated.
Usually if something become obsolete, there is some perfect
replacement! But my digging in Inet and forums gave nothing,
but "outdated" examples with 'SocketStream' class. So first
question is WHAT Phobos has to replace SocketStream?
To avoid unnecessary mail bouncing, I write upfront what I
expect from normal Socket implementation (kind of interface) :
1. Easy to use. No more stupid "UNIX sockets", "TCP types" and
so on. Just simple as this:
// Client side
auto sock = new ClientSocket("google.com", 80);
sock.WriteLine("GET / HTTP/1.0");
sock.WriteLine("Host: google.com");
sock.WriteLine();// empty line sent
// Server side:
auto svc = new ServerSocket("Bound.To.This.IP", 1000);
while ((auto ClientSock = svc.AcceptClient()) !is null) {
auto command = ClientSock.ReadLine();// this is important -
read by line, not idiotic "buffers of bytes"!
ClientSock.WriteLine(command ~ ` yourself!`);
ClientSock.Close();
}
2. Of course integration with std.stream could be nice, it
gives "for free" readLine and other methods.
3. Ability to 'get and forget': hardly all of us wanna deal
with "get portion, write portion to disk, blah". Simple
"sock.ReceiveFile(`http://porno/girl.avi`,
`c:\diploma_work.avi`)" could be enough.
Some kind of "progress report" callback would be nice.
4. SSL/TLS out-of-the-box. In example above it should be same
easy as:
auto sock = new ClientSocket("google.com", 80, Proto.TLS);
At the moment it's all I need, but hope you'll be happy too
with such interface. Sockets are SOOO important, that I cannot
believe we don't have so easy API now. Or if we have, please
share!
Thanks everybody!
Sockets in D are a thin layer over the BSD sockets, and they do
well in that aspect. What you are asking for aren't sockets, but
more like a HTTP client, have you checked
https://dlang.org/phobos/etc_c_curl.html ? It should be able to
do the functionality you are looking for. If not, there are some
packages on http://code.dlang.org/, such as
http://code.dlang.org/packages/requests or
http://code.dlang.org/packages/libhttp2 , which seem like a good
fit as well.
Sep 26 2016
On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote:
Hello, guys!
I was very surprised that module 'socketstream' was deprecated.
Usually if something become obsolete, there is some perfect
replacement! But my digging in Inet and forums gave nothing,
but "outdated" examples with 'SocketStream' class. So first
question is WHAT Phobos has to replace SocketStream?
To avoid unnecessary mail bouncing, I write upfront what I
expect from normal Socket implementation (kind of interface) :
1. Easy to use. No more stupid "UNIX sockets", "TCP types" and
so on. Just simple as this:
// Client side
auto sock = new ClientSocket("google.com", 80);
sock.WriteLine("GET / HTTP/1.0");
sock.WriteLine("Host: google.com");
sock.WriteLine();// empty line sent
// Server side:
auto svc = new ServerSocket("Bound.To.This.IP", 1000);
while ((auto ClientSock = svc.AcceptClient()) !is null) {
auto command = ClientSock.ReadLine();// this is important -
read by line, not idiotic "buffers of bytes"!
ClientSock.WriteLine(command ~ ` yourself!`);
ClientSock.Close();
}
2. Of course integration with std.stream could be nice, it
gives "for free" readLine and other methods.
3. Ability to 'get and forget': hardly all of us wanna deal
with "get portion, write portion to disk, blah". Simple
"sock.ReceiveFile(`http://porno/girl.avi`,
`c:\diploma_work.avi`)" could be enough.
Some kind of "progress report" callback would be nice.
4. SSL/TLS out-of-the-box. In example above it should be same
easy as:
auto sock = new ClientSocket("google.com", 80, Proto.TLS);
At the moment it's all I need, but hope you'll be happy too
with such interface. Sockets are SOOO important, that I cannot
believe we don't have so easy API now. Or if we have, please
share!
Thanks everybody!
-idiotic "buffers of bytes"!
It's not buffer of bytes who is idiotic... communication over
sockets are binary, not in text form. Sending structs in binary
form is much better idea than send it in text form.
e.g.
struct Message {
int magic;
int command;
int dataLength; // length of data pushed after this struct
}
then you can receive sizeof(Message), check magic, receive
dataLength of bytes and call delegate by the command int in
Message...
UNIX sockets are not stupid, only you cannot use it.
Sep 26 2016
Am Mon, 26 Sep 2016 23:40:10 +0000
schrieb Vincent <thornik gmail.com>:
1. Easy to use. No more stupid "UNIX sockets", "TCP types" and so
on. Just simple as this:
// Client side
auto sock = new ClientSocket("google.com", 80);
sock.WriteLine("GET / HTTP/1.0");
sock.WriteLine("Host: google.com");
sock.WriteLine();// empty line sent
Haha, this is not how I learned network layers at school.
You seem to want on the ...
Network Layer (3): A connection based socket using the Internet
Protocol
Transport Layer (4): A stateful connection using TCP
Application Layer (6): HTTP
Just that you don't ask for HTTP directly, but shoehorn a
packet based socket into sending microscopic strings. In this
case I recommend cURL, which you can feed with all the header
data at once and sends your complete request in one packet.
That'll also handle most of the HTTP specialties.
Not all data transmissions via IP are TCP either. A good bunch
is sent via stateless UDP. That would not be considered a
stream though. I'm just getting at the name "ClientSocket"
here, which can entail more than TCP/IP streams.
--
Marco
Sep 27 2016
Just in case, here are the relevant docs: http://dlang.org/phobos/std_net_curl.html
Sep 27 2016
Why not just create a binding to 0MQ and get much, much more than asked for? On Mon, 2016-09-26 at 23:40 +0000, Vincent via Digitalmars-d-learn wrote:Hello, guys! =20 I was very surprised that module 'socketstream' was deprecated.=C2=A0 Usually if something become obsolete, there is some perfect=C2=A0 replacement! But my digging in Inet and forums gave nothing, but=C2=A0 "outdated" examples with 'SocketStream' class. So first question=C2=A0 is WHAT Phobos has to replace SocketStream? To avoid unnecessary mail bouncing, I write upfront what I expect=C2=A0 from normal Socket implementation (kind of interface) : =20 1. Easy to use. No more stupid "UNIX sockets", "TCP types" and so=C2=A0 on. Just simple as this: =20 // Client side auto sock =3D new ClientSocket("google.com", 80); sock.WriteLine("GET / HTTP/1.0"); sock.WriteLine("Host: google.com"); sock.WriteLine();// empty line sent =20 // Server side: auto svc =3D new ServerSocket("Bound.To.This.IP", 1000); while ((auto ClientSock =3D svc.AcceptClient()) !is null) { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto command =3D ClientSock.ReadLine();// t=his is important -=C2=A0read by line, not idiotic "buffers of bytes"! ClientSock.WriteLine(command ~ ` yourself!`); ClientSock.Close(); } =20 2. Of course integration with std.stream could be nice, it gives=C2=A0 "for free" readLine and other methods. 3. Ability to 'get and forget': hardly all of us wanna deal with=C2=A0 "get portion, write portion to disk, blah". Simple=C2=A0 "sock.ReceiveFile(`http://porno/girl.avi`,=C2=A0 `c:\diploma_work.avi`)" could be enough. =C2=A0=C2=A0=C2=A0=C2=A0Some kind of "progress report" callback would be =nice.4. SSL/TLS out-of-the-box. In example above it should be same=C2=A0 easy as: =20 auto sock =3D new ClientSocket("google.com", 80, Proto.TLS); =20 =20 At the moment it's all I need, but hope you'll be happy too with=C2=A0 such interface. Sockets are SOOO important, that I cannot believe=C2=A0 we don't have so easy API now. Or if we have, please share! =20 Thanks everybody! =20--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 27 2016
On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder wrote:Why not just create a binding to 0MQ and get much, much more than asked for?http://code.dlang.org/packages/zmqd http://code.dlang.org/packages/zeromq http://code.dlang.org/packages/dzmq or use existing ones :)
Sep 27 2016
On Tue, 2016-09-27 at 10:16 +0000, JN via Digitalmars-d-learn wrote:On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder=C2=A0 wrote:Even better, except it would be good if there was one. Maybe the authors of these three can get together and make a single binding to avoid dispersion. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder=20 Why not just create a binding to 0MQ and get much, much more=C2=A0 than asked for? =20=20 http://code.dlang.org/packages/zmqd http://code.dlang.org/packages/zeromq http://code.dlang.org/packages/dzmq =20 or use existing ones :)
Sep 27 2016
On Tuesday, 27 September 2016 at 11:16:00 UTC, Russel Winder wrote:On Tue, 2016-09-27 at 10:16 +0000, JN via Digitalmars-d-learn wrote:Not really, because some of these are just pure C bindings, while some offer D wrappers for the ZeroMQ interface. Both are good to have, depending on the needs.On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder wrote:Even better, except it would be good if there was one. Maybe the authors of these three can get together and make a single binding to avoid dispersion.Why not just create a binding to 0MQ and get much, much more than asked for?http://code.dlang.org/packages/zmqd http://code.dlang.org/packages/zeromq http://code.dlang.org/packages/dzmq or use existing ones :)
Sep 27 2016
On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote:Hello, guys! I was very surprised that module 'socketstream' was deprecated. Usually if something become obsolete, there is some perfect replacement! But my digging in Inet and forums gave nothing, but "outdated" examples with 'SocketStream' class. So first question is WHAT Phobos has to replace SocketStream? To avoid unnecessary mail bouncing, I write upfront what I expect from normal Socket implementation (kind of interface) : [...]This is how a usable socket in a standard library should be http://dsfml.com/docs/sockets.html. This is using DSFML (a D bindings to SFML).
Oct 08 2016
Wrote some pretty simple sockets that you could use (Based on vibe.d though.) https://github.com/bausshf/cheetah
Oct 10 2016
On Monday, 10 October 2016 at 07:37:48 UTC, Bauss wrote:Wrote some pretty simple sockets that you could use (Based on vibe.d though.) https://github.com/bausshf/cheetahHi, Yes I saw it, but not sure. Does it make sense to use vibe.d only for sockets. I mean, it like a web framework with many dependencies etc...
Oct 10 2016
On Monday, 10 October 2016 at 07:37:48 UTC, Bauss wrote:Wrote some pretty simple sockets that you could use (Based on vibe.d though.)That's the point! STANDARD library cannot/must not rely on bloatware like vibe.d; Only small, native, non-depended socket implementation.
Dec 03 2022
On Saturday, 8 October 2016 at 17:52:25 UTC, Karabuta wrote:This is how a usable socket in a standard library should be http://dsfml.com/docs/sockets.html. This is using DSFML (a D bindings to SFML).Pity, doesn't exist anymore.
Dec 03 2022
On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote:Hello, guys! I was very surprised that module 'socketstream' was deprecated. Usually if something become obsolete, there is some perfect replacement! But my digging in Inet and forums gave nothing, but "outdated" examples with 'SocketStream' class. So first question is WHAT Phobos has to replace SocketStream?Hello, I'm agree with your main question. This looks very good http://dsfml.com/docs/sockets.html, but, there is no any answer for the question. Why 'socketstream' was deprecated when no any replacement modules? It looks strange, like you are removing feature from your app because his code old and don't write new code for same feature, and just say to users: no feature anymore, haha. So anyone know the answer?
Oct 09 2016
On Monday, October 10, 2016 01:43:54 Konstantin Kutsevalov via Digitalmars-d- learn wrote:Why 'socketstream' was deprecated when no any replacement modules? It looks strange, like you are removing feature from your app because his code old and don't write new code for same feature, and just say to users: no feature anymore, haha. So anyone know the answer?Quite some time ago, it was decided that the *stream modules as they were were unacceptable and that they needed to be replaced with something range-based (they come from early D1 and have never really been updated since), and they were marked in their documentation to indicate that they were going to be removed in the future. But apparently, no one cared enough about that functionality to actually design a replacement, and it sat there for years. So, it was finally decided that rather than just having code that was not up to our current standards sit there with a warning on it, it should be removed. So, they those modules were deprecated (and will be fully removed in the next release). I'm sure that part of what it comes down to is that ranges in generally largely slove the problem that a stream tries to solve (though std.socket unfortunately doesn't provide an easy way to get a range over a socket), making the *stream modules largely redundant, and the read, write, and peek functions in std.bitmanip do a lot of the rest of what would need to be done with a stream that isn't natively part of a range. So, enough of the functionality is there in a more general form that a replacement isn't necessarily needed (even if it might be nice), and if anyone cared enough to do it, they haven't tried to get it into Phobos (or even put it up on code.dlang.org AFAIK). Clearly, some folks use the *stream stuff, but it doesn't seem like many do, and it's also clear that - for whatever reason - no one has cared enough to come up with a replacement for Phobos. So, it's simply gone. But if someone wants to propose a replacement, they're certainly still free to do so. - Jonathan M Davis
Oct 09 2016
On Monday, 10 October 2016 at 02:54:09 UTC, Jonathan M Davis wrote:On Monday, October 10, 2016 01:43:54 Konstantin Kutsevalov via So, it's simply gone. But if someone wants to propose a replacement, they're certainly still free to do so. - Jonathan M DavisI see, thank you for answer
Oct 10 2016
On Monday, 10 October 2016 at 02:54:09 UTC, Jonathan M Davis wrote:Quite some time ago, it was decided that the *stream modules as they were were unacceptable and that they needed to be replaced with something range-basedThat's the key! Absolutely dilettantish solution of "profi", biased on ranges. Unfortunately even TECHNICALLY stream never was a "range"! It's more like "queue of bytes", where you can never be sure you even get these bytes. Moreover - "socket stream" is such a specific stream that you cannot assume even bytes data! Many protocols rely on STRINGS, so SocketStream have to have dual nature - byte-based and string-based. Even worse - if you read stupid HTTP standard, it allows for server to reply with strings (header), followed by RAW BYTES(!). Surprise! So in this light we cannot speak about ranges AT ALL. We need stream, which supports strings and at the same time bytes. And all of that in convenient way, not just "auto b = GimmeStupidHeapOfBytesWhichAreString". Anyway, it's quite unprofessional to remove SocketStream: it DOES NOT fit at all in "range" ideology (as well as, say, Window or Button) and lives own life. "Ranges" just PART of library, not a whole library! In other words not everything in a library should follow "ranges ideology". I ask to return standard SocketStream and keep it until that "smartie" (who remove it) will write fully functional replacement. Nobody will use D if maintainers will stupidly throw away classes by own wish. Keep functionality as big as possible, because D even now, after "stable language", still lie on road edge.
Dec 03 2022
On Saturday, 3 December 2022 at 11:08:53 UTC, Vincent wrote:Unfortunately even TECHNICALLY stream never was a "range"! It's more like "queue of bytes", where you can never be sure you even get these bytes.A stream is exactly a range, a "range of ranges" if more specifically. All network devices work with chunks of data (buffers), either it's 1 byte or 4096 bytes in size. So, such ranges may work either with strings (with "\n" terminator, like `byLine` or your `readLine` example), or a chunk of bytes (like `byChunk`). --- As for your request about "Easy sockets": it seems there is nothing like that available for now in the standard library. Besides, your example with google is oversimplified: for example, there is no simple way to determine the transport layer protocol for a specific domain name and port: ```d auto sock = new ClientSocket("google.com", 80); sock.WriteLine("GET / HTTP/1.0"); ``` You can technically guess between IPv4 and IPv6 by resolving the address via DNS, but you can't guess TCP vs UDP without trying to connect to a host. Moreover, there are other protocols like QUIC, which is built on top of UDP but has different semantics. However, your demand is quite understandable. There is some ongoing work toward these ideas. For example, what would you say about the following interface: ```d auto s = socket("tcp://google.com:80"); s.connect(); s.writeln("Hello world"); s.close(); ``` or, if asynchronous: ```d auto t1 = socket("tcp://google.com:80") .connect() .writeln("GET / HTTP/1.0") .readln((sock, msg) => doSomething()); auto t2 = socket("tcp://duckduckgo.com:80") .connect() .writeln("GET / HTTP/1.0") .readln((sock, msg) => doSomethingElse()); wait(t1, t2); ```
Dec 06 2022
Dne 10.10.2016 v 03:43 Konstantin Kutsevalov via Digitalmars-d-learn napsal(a):On Monday, 26 September 2016 at 23:40:10 UTC, Vincent wrote:Until some replacment will occure in phobos socketstream is and will be available through https://code.dlang.org/packages/undeadHello, guys! I was very surprised that module 'socketstream' was deprecated. Usually if something become obsolete, there is some perfect replacement! But my digging in Inet and forums gave nothing, but "outdated" examples with 'SocketStream' class. So first question is WHAT Phobos has to replace SocketStream?Hello, I'm agree with your main question. This looks very good http://dsfml.com/docs/sockets.html, but, there is no any answer for the question. Why 'socketstream' was deprecated when no any replacement modules? It looks strange, like you are removing feature from your app because his code old and don't write new code for same feature, and just say to users: no feature anymore, haha. So anyone know the answer?
Oct 09 2016