Changing some names in module "net"?

[daokoder]

I wonder if we should change net::TcpStream to net::TcpSocket. It does conform to the io::Device interface, but it is not really necessary to be called Stream, right? Calling it TcpSocket would be closer to what it really is, and be more consistent to UdpSocket.

I am also considering to change UdpSocket.send() to UdpSocket.write(), and UdpSocket.receive() to UdpSocket.read(), in order to be more consistent to the TCP type.

Then I will add a new UdpSocket.send() for sending Dao values, and UdpSocket.receive() for receiving Dao values. I really do need such methods, as they are very handy to use. Primitive values and their aggregations can be supported.

[dumblob]

I'm not against, but would it make sense to just overload the write() and read() methods even for the Dao values to maintain consistency?

[daokoder]

I'm not against, but would it make sense to just overload the write() and read() methods even for the Dao values to maintain consistency?

It would be problematic for the string type, which can be sent in two forms: raw bytes and boxed bytes with type information.

[Night-walker]

I wonder if we should change net::TcpStream to net::TcpSocket. It does conform to the io::Device interface, but it is not really necessary to be called Stream, right? Calling it TcpSocket would be closer to what it really is, and be more consistent to UdpSocket.

It's not some TCP socket. It is a connected socket you can read from and write to, which distinguishes it from TcpListener which accepts connections. Having TcpSocket and TcpListener would be confusing.

I am also considering to change UdpSocket.send() to UdpSocket.write(), and UdpSocket.receive() to UdpSocket.read(), in order to be more consistent to the TCP type.

I named them differently because 'reading from address' and writing to address seems awkward. I would have used send() and receive() in TcpStream too, but I don't like the idea of dummy read() and write() methods still necessary to satisfy io::Device interface. It may, however, be possible to provide a concrete interface for that, but I'm not sure it's worth the efforts.

Then I will add a new UdpSocket.send() for sending Dao values, and UdpSocket.receive() for receiving Dao values. I really do need such methods, as they are very handy to use. Primitive values and their aggregations can be supported.

I think you approach the problem from the wrong side. Sockets don't need to have hard-coded support for transmitting Dao data. Now there are bin::Encoder and bin::Decoder with which you can encode whatever you want, transfer it and decode back.

[Night-walker]

Generally, means for data encoding should come separately from means for data transfer, unless you implement a protocol which encompasses both. Sockets are meant to be abstract over data representation, which is the job of a higher-level layer, e.g. HTTP.

So I advise either to provide separate implementation of Dao data serialization, or to implement a dedicated full-blown L5 protocol for that.

[dumblob]

@Night-walker you're right except for the reasoning about not using read() write() and using send() receive() instead. It's still a socket, so we're literally reading and writing data to it. If it was a receiver entity, than we can send and receive data to/from it.

[daokoder]

It's not some TCP socket. It is a connected socket you can read from and write to, which distinguishes it from TcpListener which accepts connections. Having TcpSocket and TcpListener would be confusing.

I know there is a difference in handling TCP and UDP protocol. But a connected socket is still a socket, I don't think it is far off to use TcpSocket. Anyway this is not a big issue, I don't object to continue to use TcpStream. However, it might be better to split it into TcpSocket and TcpStream, and use send/receive for TcpSocket and write/read etc. for TcpStream.

It may, however, be possible to provide a concrete interface for that, but I'm not sure it's worth the efforts.

No need to complicate things.

I think you approach the problem from the wrong side. Sockets don't need to have hard-coded support for transmitting Dao data. Now there are bin::Encoder and bin::Decoder with which you can encode whatever you want, transfer it and decode back.

bin::Encoder and bin::Decoder don't suit well with my intended use scenario. What I need to is the ability to receive discrete and reconstructed Dao values. I don't want to bother with this at high level.

Generally, means for data encoding should come separately from means for data transfer, unless you implement a protocol which encompasses both. Sockets are meant to be abstract over data representation, which is the job of a higher-level layer, e.g. HTTP.

Right. I will create derived types from TcpStream/TcpSocket.

So I advise either to provide separate implementation of Dao data serialization, or to implement a dedicated full-blown L5 protocol for that.

Clearly sending and receiving Dao values requires to define a simple protocol. My intention is that on top of this simple protocol, users can easily define their own protocols, by structuring their data into appropriate tuples and send/receive these tuples directly.

And I probably cannot wait for an implementation for a full-blown L5 protocol.

[dumblob]

My intention is that on top of this simple protocol, users can easily define their own protocols, by structuring their data into appropriate tuples and send/receive these tuples directly.

And I probably cannot wait for an implementation for a full-blown L5 protocol.

msgpack is created exactly for this purpose and it's getting very widespread - apparently it's simplicity and versatility pays off.

[Night-walker]

But a connected socket is still a socket, I don't think it is far off to use TcpSocket.

Then TcpListener is not a TCP socket? We would have to rename it too, or there would be a confusing inconsistency. I was reluctant to use TcpStream name, but I really see no better option taking TcpListener into account.

However, it might be better to split it into TcpSocket and TcpStream, and use send/receive for TcpSocket and write/read etc. for TcpStream.

Why two identical types which only differ in method names?! That would have been even more puzzling. I'd rather add send() and receive() aliases to TcpStream.

Right. I will create derived types from TcpStream/TcpSocket.

Better add types which wrap sockets. Then you won't need to provide alternative TcpListener, and one will be able to use these types on an existing connection at any time, 'upgrading' it. It should be more practical this way.

Clearly sending and receiving Dao values requires to define a simple protocol. My intention is that on top of this simple protocol, users can easily define their own protocols, by structuring their data into appropriate tuples and send/receive these tuples directly.

I'm very sceptical about the use of such protocol, as it assumes that both the sender and the recipient are implemented in Dao. That is a very limiting choice for a very narrow use case. I would use a well-known binary serialization format instead.

And I probably cannot wait for an implementation for a full-blown L5 protocol.

Certain data coherency measures should still be implemented to receive Dao values 'atomically' -- together with encoding/decoding it will be an L5 protocol :)

[daokoder]

Then TcpListener is not a TCP socket? We would have to rename it too, or there would be a confusing inconsistency. I was reluctant to use TcpStream name, but I really see no better option taking TcpListener into account.

OK, I seem TcpListener and TcpStream are the logical choice now.

Better add types which wrap sockets. Then you won't need to provide alternative TcpListener, and one will be able to use these types on an existing connection at any time, 'upgrading' it. It should be more practical this way.

Then there will need some code refactoring for this. But I agree this is the better way to go.

I'm very sceptical about the use of such protocol, as it assumes that both the sender and the recipient are implemented in Dao.

If one decides to use customized protocol, I doubt he/she will use two different languages, unless for some special reason.

Certain data coherency measures should still be implemented to receive Dao values 'atomically' -- together with encoding/decoding it will be an L5 protocol :)

Receiving Dao values atomically is exactly what I need.

[Night-walker]

So, should we add send() and receive() to TcpStream or change UdpSocket to read() and write() for the sake of consistency? I would probably go for the latter then.

[dumblob]

I'd also prefer the latter, but it's not a strong preference.

[daokoder]

The later is Ok for me.

[Night-walker]

Done.