Sponsored Content
Full Discussion: QOS script
Special Forums IP Networking QOS script Post 302459421 by DGPickett on Monday 4th of October 2010 03:40:44 PM
Old 10-04-2010
A back door possibility is to use lsof to show what files and sockets are open on the server, and post-process to link socket processes to files to file size or extension. Of course, if there is a multithreaded server process, it gets fuzzy again.

Finding a way to throttle sockets that have moved too many bytes might be nasty to persistent HTTP1.1 users, a kind of usage that is friendlier to the server than file per connection, never mind ftp's two connections. If you could serve one packet out per socket in strict rotation, the long connections for big files have less effect on the new ones. Optimally, you want the oldest connection to get done, so you have fewer concurrent connections and least redo activity, yet you want the new connections to be favored for a while, since they may want little. If you can move aging connections to the long pool tagged with their start time, you can favor the young connections and allow the oldest to take from their excess bandwidth. You may have more bandwidth than the oldest connection, so what it cannot use of that excess goes to the second oldest, and so on.

I am not sure what tools facilitate this, or if any tool can tag HTTP1.1 persistent connections and tell if such a connection is not doing large files.

Packet size is maxed out for every transfer with more than MTU to move at that moment, but MTU is characteristically only 1500, not much of a challenge to fill.

Large files served out might have their sockets tagged, or be segregated on a server that is allowed less priority to the network.

Uploads are really hard, since you cannot look at the file in advance. Extensions and even Content-type: are not very reliable, easily subverted for download/upload by a zip of temporary rename. Files may be encoded to make them not sniffable for type signatures.

Just spitballing! Smilie
 

7 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

create a shell script that calls another script and and an awk script

Hi guys I have a shell script that executes sql statemets and sends the output to a file.the script takes in parameters executes sql and sends the result to an output file. #!/bin/sh echo " $2 $3 $4 $5 $6 $7 isql -w400 -U$2 -S$5 -P$3 << xxx use $4 go print"**Changes to the table... (0 Replies)
Discussion started by: magikminox
0 Replies

2. IP Networking

802 QOS/ Bandwidth Control

My question is such: I want to control the bandwidth of my users and cap there speed on the network. I was told by a Cisco rep that it is better to police or control the bandwidth at the switch and not via the router. It that the correct place to control bandwidth at the switch or would it be... (0 Replies)
Discussion started by: metallica1973
0 Replies

3. Windows & DOS: Issues & Discussions

QOS packet scheduler and group policy

hi, did anyone know how to configure a priority of dns ports (and other ports) on QOS on windows 2003? hard to understand the group policy "explain" tab on 'qos packet scheduler', no elaboration on how to use it. thanks for any comment you may add. ---------- Post updated at 05:03 PM... (0 Replies)
Discussion started by: itik
0 Replies

4. IP Networking

QOS using tc

Hello all my friends Please Read to understand my problem I have 1 MB bandwidth and two networks then i did traffic control on my two internal interfaces i.e eth1(192.168.3.0/24) and eth2(172.16.3.0/24) (internal) and eth0 (outside) Then i divided my bandwidth using tc command with the... (3 Replies)
Discussion started by: rink
3 Replies

5. IP Networking

Internet QOS woes

I'm looking for recommendations for a general problem. Apparently (that is according to my boss and coworkers) I am responsible for guaranteeing quality of service to our remote MySQL server during the course of the day. They may run a complete database restore for any number of reasons and are... (1 Reply)
Discussion started by: Astrocloud
1 Replies

6. Shell Programming and Scripting

Script will keep checking running status of another script and also restart called script at night

I am using blow script :-- #!/bin/bash FIND=$(ps -elf | grep "snmp_trap.sh" | grep -v grep) #check snmp_trap.sh is running or not if then # echo "process found" exit 0; else echo "process not found" exec /home/Ketan_r /snmp_trap.sh 2>&1 & disown -h ... (1 Reply)
Discussion started by: ketanraut
1 Replies

7. Shell Programming and Scripting

Shell script works fine as a standalone script but not as part of a bigger script

Hello all, I am facing a weird issue while executing a code below - #!/bin/bash cd /wload/baot/home/baotasa0/sandboxes_finance/ext_ukba_bde/pset sh UKBA_publish.sh UKBA 28082015 3 if then echo "Param file conversion for all the areas are completed, please check in your home directory"... (2 Replies)
Discussion started by: ektubbe
2 Replies
LISTEN(2)						      BSD System Calls Manual							 LISTEN(2)

NAME
listen -- listen for connections on a socket LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <sys/types.h> #include <sys/socket.h> int listen(int s, int backlog); DESCRIPTION
To accept connections, a socket is first created with socket(2), a willingness to accept incoming connections and a queue limit for incoming connections are specified with listen(), and then the connections are accepted with accept(2). The listen() system call applies only to sockets of type SOCK_STREAM or SOCK_SEQPACKET. The backlog argument defines the maximum length the queue of pending connections may grow to. The real maximum queue length will be 1.5 times more than the value specified in the backlog argument. A subsequent listen() system call on the listening socket allows the caller to change the maximum queue length using a new backlog argument. If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED, or, in the case of TCP, the connection will be silently dropped. Current queue lengths of listening sockets can be queried using netstat(1) command. Note that before FreeBSD 4.5 and the introduction of the syncache, the backlog argument also determined the length of the incomplete connec- tion queue, which held TCP sockets in the process of completing TCP's 3-way handshake. These incomplete connections are now held entirely in the syncache, which is unaffected by queue lengths. Inflated backlog values to help handle denial of service attacks are no longer neces- sary. The sysctl(3) MIB variable kern.ipc.soacceptqueue specifies a hard limit on backlog; if a value greater than kern.ipc.soacceptqueue or less than zero is specified, backlog is silently forced to kern.ipc.soacceptqueue. INTERACTION WITH ACCEPT FILTERS
When accept filtering is used on a socket, a second queue will be used to hold sockets that have connected, but have not yet met their accept filtering criteria. Once the criteria has been met, these sockets will be moved over into the completed connection queue to be accept(2)ed. If this secondary queue is full and a new connection comes in, the oldest socket which has not yet met its accept filter criteria will be terminated. This secondary queue, like the primary listen queue, is sized according to the backlog argument. RETURN VALUES
The listen() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The listen() system call will fail if: [EBADF] The argument s is not a valid descriptor. [EDESTADDRREQ] The socket is not bound to a local address, and the protocol does not support listening on an unbound socket. [EINVAL] The socket is already connected, or in the process of being connected. [ENOTSOCK] The argument s is not a socket. [EOPNOTSUPP] The socket is not of a type that supports the operation listen(). SEE ALSO
netstat(1), accept(2), connect(2), socket(2), sysctl(3), sysctl(8), accept_filter(9) HISTORY
The listen() system call appeared in 4.2BSD. The ability to configure the maximum backlog at run-time, and to use a negative backlog to request the maximum allowable value, was introduced in FreeBSD 2.2. The kern.ipc.somaxconn sysctl(3) has been replaced with kern.ipc.soacceptqueue in FreeBSD 10.0 to prevent confusion about its actual functionality. The original sysctl(3) kern.ipc.somaxconn is still available but hidden from a sysctl(3) -a output so that existing applications and scripts continue to work. BSD
July 15, 2014 BSD
All times are GMT -4. The time now is 10:05 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy