This document discusses various issues in client/server programming and network server design. It covers topics like identifying servers, UDP and TCP client design, specifying local addresses, partial socket closes, concurrent vs iterative servers, and design alternatives like one process per client, preforked servers, and prethreaded servers. The best design depends on factors like expected client load, transaction sizes, and available system resources. Understanding these issues and testing alternatives is important for choosing an optimal server architecture.
Networking Fundamentals: Transport Protocols (TCP and UDP)Andriy Berestovskyy
Transport Layer of TCP/IP. Transmission Control Protocol (TCP) basics and network sockets explained. How TCP connection get established, error recovered and terminated.
User Datagram Protocol and its comparison to TCP. Quality of Service (QoS).
Networking Fundamentals: Transport Protocols (TCP and UDP)Andriy Berestovskyy
Transport Layer of TCP/IP. Transmission Control Protocol (TCP) basics and network sockets explained. How TCP connection get established, error recovered and terminated.
User Datagram Protocol and its comparison to TCP. Quality of Service (QoS).
Let's dive under the hood of Java network applications. We plan to have a deep look to classic sockets and NIO having live coding examples. Then we discuss performance problems of sockets and find out how NIO can help us to handle 10000+ connections in a single thread. And finally we learn how to build high load application server using Netty.
https://github.com/kslisenko/java-networking
Kernel Recipes 2013 - Deciphering OopsiesAnne Nicolas
The Linux kernel is a very complex beast living in millions of households and data centers around the world. Normally, you’re not supposed to notice its presence but when it gets cranky because of something not suiting it, it spits crazy messages called colloquially
oopses and panics.
In this talk, we’re going to try to understand how to read those messages in order to be able to address its complaints so that it can get back to work for us.
Die monatlichen Anlässe in Zusammenarbeit mit dem Swiss IPv6 Council behandeln verschiedene technische Themenbereiche von IPv6.
Das Referat von Jen Linkova vom 30. November 2015 widmete sich dem Neighbor Discovery Protokoll, einem Schlüsselmechanismus um Verbindungen zwischen IPv6 Knotenpunkten und LANs aufzubauen. Die Referentin fokussierte sich in der Präsentation auf die technischen Details des Designs, der Implementierung sowie Sicherheitsaspekten.
Gerne stellen wir Ihnen die Präsentation zum Anschauen und Herunterladen zur Verfügung. Haben Sie Feedback zum Event? Wir sind gespannt auf Ihre Meinung.
Let's dive under the hood of Java network applications. We plan to have a deep look to classic sockets and NIO having live coding examples. Then we discuss performance problems of sockets and find out how NIO can help us to handle 10000+ connections in a single thread. And finally we learn how to build high load application server using Netty.
https://github.com/kslisenko/java-networking
Kernel Recipes 2013 - Deciphering OopsiesAnne Nicolas
The Linux kernel is a very complex beast living in millions of households and data centers around the world. Normally, you’re not supposed to notice its presence but when it gets cranky because of something not suiting it, it spits crazy messages called colloquially
oopses and panics.
In this talk, we’re going to try to understand how to read those messages in order to be able to address its complaints so that it can get back to work for us.
Die monatlichen Anlässe in Zusammenarbeit mit dem Swiss IPv6 Council behandeln verschiedene technische Themenbereiche von IPv6.
Das Referat von Jen Linkova vom 30. November 2015 widmete sich dem Neighbor Discovery Protokoll, einem Schlüsselmechanismus um Verbindungen zwischen IPv6 Knotenpunkten und LANs aufzubauen. Die Referentin fokussierte sich in der Präsentation auf die technischen Details des Designs, der Implementierung sowie Sicherheitsaspekten.
Gerne stellen wir Ihnen die Präsentation zum Anschauen und Herunterladen zur Verfügung. Haben Sie Feedback zum Event? Wir sind gespannt auf Ihre Meinung.
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
help.mbaassignments@gmail.com
or
call us at : 08263069601
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
help.mbaassignments@gmail.com
or
call us at : 08263069601
When we desire a communication between two applications possibly running on different machines, we need sockets. This presentation aims to provide knowledge of basic socket programming to undergraduate students. Basically, this presentation gives the importance of socket in the area of networking and Unix Programming. The presentation of Topic (Sockets) has designed according to the Network Programming Subject, B.Tech, 6th Semester syllabus of Punjab Technical University Kapurthala, Punjab.
Building a Raspberry Pi Robot with Dot NET 8, Blazor and SignalR - Slides Onl...Peter Gallagher
In this session delivered at Leeds IoT, I talk about how you can control a 3D printed Robot Arm with a Raspberry Pi, .NET 8, Blazor and SignalR.
I also show how you can use a Unity app on an Meta Quest 3 to control the arm VR too.
You can find the GitHub repo and workshop instructions here;
https://bit.ly/dotnetrobotgithub
MATHEMATICS BRIDGE COURSE (TEN DAYS PLANNER) (FOR CLASS XI STUDENTS GOING TO ...PinkySharma900491
Class khatm kaam kaam karne kk kabhi uske kk innings evening karni nnod ennu Tak add djdhejs a Nissan s isme sniff kaam GCC bagg GB g ghan HD smart karmathtaa Niven ken many bhej kaam karne Nissan kaam kaam Karo kaam lal mam cell pal xoxo
1. Netprog 2002 - Client/Server Issues1
Issues in Client/ServerIssues in Client/Server
ProgrammingProgramming
Refs: Chapter 27Refs: Chapter 27
2. Netprog 2002 - Client/Server Issues2
Issues in Client ProgrammingIssues in Client Programming
Identifying the Server.Identifying the Server.
Looking up a IP address.Looking up a IP address.
Looking up a well known portLooking up a well known port
name.name.
Specifying a local IP address.Specifying a local IP address.
UDP client design.UDP client design.
TCP client design.TCP client design.
3. Netprog 2002 - Client/Server Issues3
Identifying the ServerIdentifying the Server
Options:Options:
– hard-coded into the client program.hard-coded into the client program.
– require that the user identify the server.require that the user identify the server.
– read from a configuration file.read from a configuration file.
– use a separate protocol/network service touse a separate protocol/network service to
lookup the identity of the server.lookup the identity of the server.
4. Netprog 2002 - Client/Server Issues4
Identifying a TCP/IP server.Identifying a TCP/IP server.
Need an IP address, protocol and port.Need an IP address, protocol and port.
– We often useWe often use host nameshost names instead of IPinstead of IP
addresses.addresses.
– usually the protocol (UDP vs. TCP) is notusually the protocol (UDP vs. TCP) is not
specified by the user.specified by the user.
– often the port is not specified by the user.often the port is not specified by the user.
Can you name one common exception ?Can you name one common exception ?
5. Netprog 2002 - Client/Server Issues5
Services and PortsServices and Ports
Many services are available via “wellMany services are available via “well
known” addresses (names).known” addresses (names).
There is a mapping of service names toThere is a mapping of service names to
port numbers:port numbers:
struct *servent getservbyname(struct *servent getservbyname(
char *service, char *protocol );char *service, char *protocol );
servent->s_portservent->s_port is the port numberis the port number
in network byte order.in network byte order.
6. Netprog 2002 - Client/Server Issues6
Specifying a Local AddressSpecifying a Local Address
When a client creates and binds aWhen a client creates and binds a
socket it must specify a local port andsocket it must specify a local port and
IP address.IP address.
Typically a client doesn’t care what portTypically a client doesn’t care what port
it is on:it is on:
haddr->port = htons(0);haddr->port = htons(0);
give me any available port !give me any available port !
7. Netprog 2002 - Client/Server Issues7
Local IP addressLocal IP address
A client can also ask the operating systemA client can also ask the operating system
to take care of specifying the local IPto take care of specifying the local IP
address:address:
haddr->sin_addr.s_addr=haddr->sin_addr.s_addr=
htonl(INADDR_ANY);htonl(INADDR_ANY);
Give me the appropriate addressGive me the appropriate address
8. Netprog 2002 - Client/Server Issues8
UDP Client DesignUDP Client Design
Establish server address (IP and port).Establish server address (IP and port).
Allocate a socket.Allocate a socket.
Specify that any valid local port and IPSpecify that any valid local port and IP
address can be used.address can be used.
Communicate with server (send, recv)Communicate with server (send, recv)
Close the socket.Close the socket.
9. Netprog 2002 - Client/Server Issues9
Connected mode UDPConnected mode UDP
A UDP client can call connect() toA UDP client can call connect() to
establishestablish the address of the server.the address of the server.
The UDP client can then use read() andThe UDP client can then use read() and
write() or send() and recv().write() or send() and recv().
A UDP client using a connected modeA UDP client using a connected mode
socket can only talk to one serversocket can only talk to one server
(using the connected-mode socket).(using the connected-mode socket).
10. Netprog 2002 - Client/Server Issues10
TCP Client DesignTCP Client Design
Establish server address (IP and port).Establish server address (IP and port).
Allocate a socket.Allocate a socket.
Specify that any valid local port and IPSpecify that any valid local port and IP
address can be used.address can be used.
Call connect()Call connect()
Communicate with server (read,write).Communicate with server (read,write).
Close the connection.Close the connection.
11. Netprog 2002 - Client/Server Issues11
Closing a TCP socketClosing a TCP socket
Many TCP based application protocolsMany TCP based application protocols
support multiple requests and/orsupport multiple requests and/or
variable length requests over a singlevariable length requests over a single
TCP connection.TCP connection.
How does the server known when theHow does the server known when the
client is done (and it is OK to close theclient is done (and it is OK to close the
socket) ?socket) ?
12. Netprog 2002 - Client/Server Issues12
Partial ClosePartial Close
One solution is for the client to shutOne solution is for the client to shut
down only it’s writing end of the socket.down only it’s writing end of the socket.
TheThe shutdown() system call providessystem call provides
this function.this function.
shutdown( int s, int direction);shutdown( int s, int direction);
– direction can be 0 to close the reading enddirection can be 0 to close the reading end
or 1 to close the writing end.or 1 to close the writing end.
– shutdown sends info to the other process!shutdown sends info to the other process!
13. Netprog 2002 - Client/Server Issues13
TCP sockets programmingTCP sockets programming
Common problem areas:Common problem areas:
– null termination of strings.null termination of strings.
– reads don’t correspond to writes.reads don’t correspond to writes.
– synchronization (including close()).synchronization (including close()).
– ambiguous protocol.ambiguous protocol.
14. Netprog 2002 - Client/Server Issues14
TCP ReadsTCP Reads
Each call to read() on a TCP socketEach call to read() on a TCP socket
returns any available data (up to areturns any available data (up to a
maximum).maximum).
TCP buffers data at both ends of theTCP buffers data at both ends of the
connection.connection.
You must be prepared to accept data 1You must be prepared to accept data 1
byte at a time from a TCP socket!byte at a time from a TCP socket!
16. Netprog 2002 - Client/Server Issues16
Concurrent vs. IterativeConcurrent vs. Iterative
Iterative
Small, fixed size requests
Easy to program
Iterative
Small, fixed size requests
Easy to program
Concurrent
Large or variable size requests
Harder to program
Typically uses more system resources
Concurrent
Large or variable size requests
Harder to program
Typically uses more system resources
17. Netprog 2002 - Client/Server Issues17
Connectionless vs.Connectionless vs.
Connection-OrientedConnection-Oriented
Connection-Oriented
EASY TO PROGRAM
transport protocol handles the tough stuff.
requires separate socket for each connection.
Connection-Oriented
EASY TO PROGRAM
transport protocol handles the tough stuff.
requires separate socket for each connection.
Connectionless
less overhead
no limitation on number of clients
Connectionless
less overhead
no limitation on number of clients
18. Netprog 2002 - Client/Server Issues18
StatelessnessStatelessness
State:State: Information that a serverInformation that a server
maintains about the status of ongoingmaintains about the status of ongoing
client interactions.client interactions.
Connectionless servers that keep stateConnectionless servers that keep state
information must be designed carefully!information must be designed carefully!
Messages can be duplicated!Messages can be duplicated!
19. Netprog 2002 - Client/Server Issues19
The Dangers of StatefullnessThe Dangers of Statefullness
Clients can go down at any time.Clients can go down at any time.
Client hosts can reboot many times.Client hosts can reboot many times.
The network can lose messages.The network can lose messages.
The network can duplicate messages.The network can duplicate messages.
20. Netprog 2002 - Client/Server Issues20
Concurrent ServerConcurrent Server
Design AlternativesDesign Alternatives
One child per clientOne child per client
Spawn one thread per clientSpawn one thread per client
Preforking multiple processesPreforking multiple processes
Prethreaded ServerPrethreaded Server
21. Netprog 2002 - Client/Server Issues21
One child per clientOne child per client
Traditional Unix server:Traditional Unix server:
– TCP: after call toTCP: after call to accept(),accept(), callcall fork().fork().
– UDP: afterUDP: after recvfrom(),recvfrom(), callcall fork().fork().
– Each process needs only a few sockets.Each process needs only a few sockets.
– Small requests can be serviced in a smallSmall requests can be serviced in a small
amount of time.amount of time.
Parent process needs to clean up afterParent process needs to clean up after
children!!!! (callchildren!!!! (call wait()wait() ).).
22. Netprog 2002 - Client/Server Issues22
One thread per clientOne thread per client
Almost like using fork - callAlmost like using fork - call
pthread_create instead.pthread_create instead.
Using threads makes it easier (lessUsing threads makes it easier (less
overhead) to have sibling processesoverhead) to have sibling processes
share information.share information.
Sharing information must be doneSharing information must be done
carefully (use pthread_mutex)carefully (use pthread_mutex)
23. Netprog 2002 - Client/Server Issues23
PrePrefork()fork()’d Server’d Server
Creating a new process for each clientCreating a new process for each client
is expensive.is expensive.
We can create a bunch of processes,We can create a bunch of processes,
each of which can take care of a client.each of which can take care of a client.
Each child process is an iterativeEach child process is an iterative
server.server.
24. Netprog 2002 - Client/Server Issues24
PrePrefork()fork()’d TCP Server’d TCP Server
Initial process creates socket and bindsInitial process creates socket and binds
to well known address.to well known address.
Process now callsProcess now calls fork()fork() a bunch ofa bunch of
times.times.
All children callAll children call accept().accept().
The next incoming connection will beThe next incoming connection will be
handed to one child.handed to one child.
25. Netprog 2002 - Client/Server Issues25
PreforkingPreforking
As the book shows, having too manyAs the book shows, having too many
preforked children can be bad.preforked children can be bad.
Using dynamic process allocationUsing dynamic process allocation
instead of a hard-coded number ofinstead of a hard-coded number of
children can avoid problems.children can avoid problems.
The parent process just manages theThe parent process just manages the
children, doesn’t worry about clients.children, doesn’t worry about clients.
26. Netprog 2002 - Client/Server Issues26
Sockets library vs. system callSockets library vs. system call
A preforked TCP server won’t usuallyA preforked TCP server won’t usually
work the way we want ifwork the way we want if socketssockets is notis not
part of the kernel:part of the kernel:
– calling accept() is a library call, not ancalling accept() is a library call, not an
atomic operation.atomic operation.
We can get around this by making sureWe can get around this by making sure
only one child calls accept() at a timeonly one child calls accept() at a time
using some locking scheme.using some locking scheme.
27. Netprog 2002 - Client/Server Issues27
Prethreaded ServerPrethreaded Server
Same benefits as preforking.Same benefits as preforking.
Can also have the main thread do allCan also have the main thread do all
the calls to accept() and hand off eachthe calls to accept() and hand off each
client to an existing thread.client to an existing thread.
28. Netprog 2002 - Client/Server Issues28
What’s the best server designWhat’s the best server design
for my application?for my application?
Many factors:Many factors:
– expected number of simultaneous clients.expected number of simultaneous clients.
– Transaction size (time to compute orTransaction size (time to compute or
lookup the answer)lookup the answer)
– Variability in transaction size.Variability in transaction size.
– Available system resources (perhaps whatAvailable system resources (perhaps what
resources can be required in order to runresources can be required in order to run
the service).the service).
29. Netprog 2002 - Client/Server Issues29
Server DesignServer Design
It is important to understand the issuesIt is important to understand the issues
and options.and options.
Knowledge of queuing theory can be aKnowledge of queuing theory can be a
big help.big help.
You might need to test a fewYou might need to test a few
alternatives to determine the bestalternatives to determine the best
design.design.