Open arthurkiller opened 7 years ago
Thank you for the suggestions.
Using reflection here is not necessary, but it's a good exercise.
Thank you for suggestions.
About next major update, I've almost finished reconstruction of core code.
Since you are interested in this project, you can check it out here https://github.com/lixin9311/shadowsocks-go/tree/next
Currently, only the server program works. But it's really easy to use the package. Just import and a few lines of code..
func run(port, password string, auth bool) {
ln, err := ss.Listen("tcp", ":"+port, config)
if err != nil {
return
}
defer ln.Close()
for {
conn, host, err := ln.Accept()
if err != nil {
return
}
remote, _ := net.Dial("tcp", host)
go ss.PipeThenClose(conn, remote)
go ss.PipeThenClose(remote, conn)
}
}
func runUDP(port, password string, auth bool) {
SecurePacketConn, err := ss.ListenPacket("udp", ":"+port, config)
if err != nil {
return
}
defer SecurePacketConn.Close()
buf := make([]byte, 4096)
for {
n, src, err := SecurePacketConn.ReadFrom(buf)
if err != nil {
return
}
host, headerLen, compatibleMode, err := ss.UDPGetRequest(buf[:n], auth)
if err != nil {
continue
}
if compatibleMode {
ss.ForwardUDPConn(SecurePacketConn.ForceOTA(), src, host, buf[:n], headerLen)
} else {
ss.ForwardUDPConn(SecurePacketConn, src, host, buf[:n], headerLen)
}
}
}
A basic server will be set up.
There are some inconsistencies in the code for now, like the config, because it's still WIP.
Next step, I'm going to finish the reconstruction and improve client and server program.
Awesome work. Thx a lot dude
@lixin9311 After really a long time I finished the reconstruct based on your next branch.
@lixin9311 how do you think about this
I have come out a suit of encryption interface for Encrypter packet.
We will get 4 interface
type AEADCipher interface {
KeySize() int
SaltSize() int
Encrypter(salt []byte) (cipher.AEAD, error)
Decrypter(salt []byte) (cipher.AEAD, error)
}
type StreamCipher interface {
KeySize() int
IVSize() int
Encrypter(iv []byte) cipher.Stream
Decrypter(iv []byte) cipher.Stream
}
type ConnectionCoder interface {
Read([]byte) (int, error)
Write([]byte) (int, error)
}
type PacketCoder interface {
ReadFrom([]byte) (int, net.Addr, error)
WriteTo([]byte, net.Addr) (int, error)
}
Combine them and you can get 4 Cipher
type AEADConnectionCipher interface {
AEADCipher
ConnectionCoder
}
type AEADPacketCipher interface {
AEADCipher
PacketCoder
}
type StreamConnectionCipher interface {
StreamCipher
ConnectionCoder
}
type StreamPacketCipher interface {
StreamCipher
PacketCoder
}
This can be easy to extend and with low coupling. On the other hand, this can be a little complicated.
I want this repo not only a cmd tool but also easy to extend and can be used as a package for golang server developer.
@Galaxy0419 @Aniark @lixin9311
And here also give out a TODO list, some feature on this is WIP and some is TBD/TODO
I wander the priority of this list. (Now it is my priority)
I have read this repo and here is some advises:
make repo pass go vet & golint. This can make the code more go-style and convenient to generate Godoc. And more comment will make it easy for other to read
Use less reflection in code. We have test the go reflection, it's convenient but cost much. There should have a try with other way to bypass the reflection if possible.
Every file should have a unit test
I think the log should change into a faster log (perhaps zap is a good choice) and unique the log with one logger just identify them by different level. Better way is to make log a interface for user to implement it.
Config should be fast to use and human readable, here you can get some config lib to do this work. (Configo \ viper).
Is leaky buffer necessary? Why not use a pool instead? Is that faster?
Can Merge sort be changed by Standard library qsort? Why we have to wrote a DIY sort lib ourself?
no more <( ̄3 ̄)>
Last day of work before new year , forgive me give about so many suggestions. I must be lacking of work LOL.
Happy new year dude