Hey Arpit, in this single threaded sync web server, when a new client tries to connect and fires a bunch of commands (while some other client is already connected to the server via the socket), is there any configurable limit, as to how many bytes of commands can be buffered in the socket, which the other client is trying to send? Example: You showed at 12:18, that the client pushed a command Arpit and as soon as it got connected, the server printed this. What if this client sent huge GBs of commands? Would the socket connection give some memory buffer error theoritically?
Just read online, that both client and server maintain a standard socket receive buffer and keep exchanging it's size as well during packet exchanges. That curbs how many bytes to be sent over the TCP socket connection.
Hey, In the inner for loop,why are you breaking only on graceful end to the connection. Shouldn't you break from the for loop irrespective of whether the connection broke gracefully or not?
Thanks Arpit for the response. However i think based on the declaration, []byte lools like a slice declaration. Can you please reiterate? I tried testing on playground with reflect and it returned true for slice, not array, I may be missing something here but can you check again? Thanks. (youtube isnt allowing to post link to the playground)
// You can edit this code! // Click here and start typing. package main import ( "fmt" "reflect" ) func checkType(v interface{}) { switch reflect.TypeOf(v).Kind() { case reflect.Slice: fmt.Println("It's a slice") case reflect.Array: fmt.Println("It's an array") default: fmt.Println("It's something else") } } func main() { var buff []byte = make([]byte, 512) checkType(buff) } this was my playground code.
Very nice ! Single threaded is best for security and its intelligient designing. Keeping multiple threads open to accept concurrent connections ,even though clients are limited, is not an intelligent programming.
it's great explanation about tcp connection , single and multi threaded & redis cli client communication
Arpit, thanks for the awesome videos!! Such an insightful explanation
Can't wait for the next one
Hey Neha,
these videos are part of my Redis internals course. More details arpitbhayani.me/redis-internals/
This is amazing. Got me excited to learn advanced Go. I have always been a JVM guy 😀
Sounds too much similar
yo dude, you can recommend a starting point tolearn Go? any resource or something@@Md_sadiq_Md
Nice 👍..series...love redis
which book/resource is best to learn golang for beginners and good at it, espically for a person coming from java background?
Hey Arpit, in this single threaded sync web server, when a new client tries to connect and fires a bunch of commands (while some other client is already connected to the server via the socket), is there any configurable limit, as to how many bytes of commands can be buffered in the socket, which the other client is trying to send?
Example: You showed at 12:18, that the client pushed a command Arpit and as soon as it got connected, the server printed this. What if this client sent huge GBs of commands? Would the socket connection give some memory buffer error theoritically?
Just read online, that both client and server maintain a standard socket receive buffer and keep exchanging it's size as well during packet exchanges. That curbs how many bytes to be sent over the TCP socket connection.
Hey, In the inner for loop,why are you breaking only on graceful end to the connection. Shouldn't you break from the for loop irrespective of whether the connection broke gracefully or not?
Do you teach GoLang?
Awesome 😍
Awesome Explanation Arpit :)
Why have you not used init() function in main for setting up flags and all
No specific reason
How did you learn go lang ? What made you learn go lang ?
We all adopted it to build Microservices back in 2016.
The performance is really solid. Plus strongly typed. Plus lean GC. Plus low-level APIs.
@@AsliEngineering thank you ..
hey bhaiya great video . also if you don't mind can you please tell me your vs code theme 😅
Can i ask why using read(buff[:]) and not read(buff)? buff is a slice here, right?
Buf is an array and not a slice.
Thanks Arpit for the response. However i think based on the declaration, []byte lools like a slice declaration.
Can you please reiterate? I tried testing on playground with reflect and it returned true for slice, not array, I may be missing something here but can you check again? Thanks.
(youtube isnt allowing to post link to the playground)
// You can edit this code!
// Click here and start typing.
package main
import (
"fmt"
"reflect"
)
func checkType(v interface{}) {
switch reflect.TypeOf(v).Kind() {
case reflect.Slice:
fmt.Println("It's a slice")
case reflect.Array:
fmt.Println("It's an array")
default:
fmt.Println("It's something else")
}
}
func main() {
var buff []byte = make([]byte, 512)
checkType(buff)
}
this was my playground code.
Very nice ! Single threaded is best for security and its intelligient designing. Keeping multiple threads open to accept concurrent connections ,even though clients are limited, is not an intelligent programming.