Category Archives: IT

Linux Iptables apache 1

IT 
*filter

#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allow SSH connections
#
#  The -dport number should be the same port number you set in sshd_config
#
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ping
-A INPUT -p icmp -j ACCEPT

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

browser caching control from server

IT

.htaccess

ExpiresActive On
ExpiresByType text/html “access plus 1 seconds”
ExpiresByType image/gif “access plus 2 years”
ExpiresByType image/jpeg “access plus 2 years”
ExpiresByType image/png “access plus 2 years”
ExpiresByType text/css “access plus 2 years”
ExpiresByType text/javascript “access plus 2 years”
ExpiresByType application/x-javascript “access plus 2 years”
ExpiresByType image/ico “access plus 2 years”

Message Length

IT,

4.4 Message Length

The transfer-length of a message is the length of the message-body as   it appears in the message; that is, after any transfer-codings have   been applied. When a message-body is included with a message, the   transfer-length of that body is determined by one of the following   (in order of precedence):

1.Any response message which “MUST NOT” include a message-body (such     as the 1xx, 204, and 304 responses and any response to a HEAD     request) is always terminated by the first empty line after the     header fields, regardless of the entity-header fields present in     the message.

2.If a Transfer-Encoding header field (section 14.41) is present and     has any value other than “identity”, then the transfer-length is     defined by use of the “chunked” transfer-coding (section 3.6),     unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its     decimal value in OCTETs represents both the entity-length and the     transfer-length. The Content-Length header field MUST NOT be sent     if these two lengths are different (i.e., if a Transfer-Encoding

     header field is present). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored.

4.If the message uses the media type “multipart/byteranges”, and the     transfer-length is not otherwise specified, then this self-     delimiting media type defines the transfer-length. This media type     MUST NOT be used unless the sender knows that the recipient can parse     it; the presence in a request of a Range header with multiple byte-     range specifiers from a 1.1     client implies that the client can parse multipart/byteranges responses.

       A range header might be forwarded by a 1.0 proxy that does not
       understand multipart/byteranges; in this case the server MUST
       delimit the message using methods defined in items 1,3 or 5 of
       this section.

5.By the server closing the connection. (Closing the connection     cannot be used to indicate the end of a request body, since that     would leave no possibility for the server to send back a response.)

For compatibility with HTTP/1.0 applications, HTTP/1.1 requests   containing a message-body MUST include a valid Content-Length header   field unless the server is known to be HTTP/1.1 compliant. If a   request contains a message-body and a Content-Length is not given,   the server SHOULD respond with 400 (bad request) if it cannot   determine the length of the message, or with 411 (length required) if   it wishes to insist on receiving a valid Content-Length.

All HTTP/1.1 applications that receive entities MUST accept the   “chunked” transfer-coding (section 3.6), thus allowing this mechanism   to be used for messages when the message length cannot be determined   in advance.

Messages MUST NOT include both a Content-Length header field and a   non-identity transfer-coding. If the message does include a non-   identity transfer-coding, the Content-Length MUST be ignored.

When a Content-Length is given in a message where a message-body is   allowed, its field value MUST exactly match the number of OCTETs in   the message-body. HTTP/1.1 user agents MUST notify the user when an   invalid length is received and detected.

review IOCP

IT,

A:

Create IO_HANDLE

Creat thread to process GetQueuedCompletionStatus

A:: AllocateContext for reference back when IOCP return

A::Write  WSASend  SetReferenc_WriteComplete

A::Read   WSARecv  SetReference_ReadComplete

A::OnWriteComplete

A::OnReadComplete

Interprocess Synchronization

IT,

Interprocess Synchronization

            8 out of 18 rated this helpful – Rate this topic

Multiple processes can have handles to the same event, mutex, semaphore, or timer object, so these objects can be used to accomplish interprocess synchronization. The process that creates an object can use the handle returned by the creation function (CreateEvent,  CreateMutex,  CreateSemaphore, or  CreateWaitableTimer). Other processes can open a handle to the object by using its name, or through inheritance or duplication. For more information, see the following topics:

 

zlib

IT, ,

Download zlib-1.2.8.tar.gz

nmake -f win32/Makefile.msc

copy zlib.h zconf.h and zlib.lib

 

int  uncompress3 (int type,Bytef *dest, uLongf *destLen,const Bytef *source,uLong sourceLen) {  int nWindowBites;  if(1==type)  {   nWindowBites=15;  }  else if(2==type)  {   nWindowBites=-15;  }  else  {   nWindowBites=15+16;  }     z_stream stream;     int err;

stream.next_in = (z_const Bytef *)source;     stream.avail_in = (uInt)sourceLen;     /* Check for source > 64K on 16-bit machine: */     if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR;

stream.next_out = dest;     stream.avail_out = (uInt)*destLen;     if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;

stream.zalloc = (alloc_func)0;     stream.zfree = (free_func)0;

//err = inflateInit(&stream);  err = inflateInit2 (&stream,nWindowBites);     if (err != Z_OK) return err;

err = inflate(&stream, Z_FINISH);     if (err != Z_STREAM_END) {         inflateEnd(&stream);         if (err == Z_NEED_DICT || (err == Z_BUF_ERROR && stream.avail_in == 0))             return Z_DATA_ERROR;         return err;     }     *destLen = stream.total_out;

err = inflateEnd(&stream);     return err; }

int  compress3 (int type,     Bytef *dest,     uLongf *destLen,     const Bytef *source,     uLong sourceLen) {  //type 1 = Deflate, 2= raw, 3 = Gzip  int nWindowBites;  if(1==type)  {   nWindowBites=15;  }  else if(2==type)  {   nWindowBites=-15;  }  else  {   nWindowBites=15+16;  }  z_stream stream;     int err;

stream.next_in = (z_const Bytef *)source;     stream.avail_in = (uInt)sourceLen; #ifdef MAXSEG_64K     /* Check for source > 64K on 16-bit machine: */     if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR; #endif     stream.next_out = dest;     stream.avail_out = (uInt)*destLen;     if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;

stream.zalloc = (alloc_func)0;     stream.zfree = (free_func)0;     stream.opaque = (voidpf)0;

//err = deflateInit(&stream, level);    err = deflateInit2(&stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED ,nWindowBites,8,Z_DEFAULT_STRATEGY);

if (err != Z_OK) return err;

err = deflate(&stream, Z_FINISH);     if (err != Z_STREAM_END) {         deflateEnd(&stream);         return err == Z_OK ? Z_BUF_ERROR : err;     }     *destLen = stream.total_out;

err = deflateEnd(&stream);     return err; }

int _tmain(int argc, _TCHAR* argv[]) {  unsigned char arr1[255];  unsigned char arr2[255];  unsigned char arr3[255];  unsigned long nTargetLen=255;  unsigned long nTargetLen2=255;  memset(arr1,0,255);  memset(arr2,0,255);  memcpy(arr1,”hello”,sizeof(“hello”));  int ret=compress3(1,arr2,&nTargetLen,arr1,sizeof(“hello”));

ret=uncompress3(1,arr3,&nTargetLen2,arr2,nTargetLen);

memset(arr3,0,255);  ret=compress3(2,arr2,&nTargetLen,arr1,sizeof(“hello”));

while(Z_BUF_ERROR==uncompress3(2,arr3,&nTargetLen2,arr2,nTargetLen))  {   nTargetLen2*=2;  }  memset(arr3,0,255);

while(Z_BUF_ERROR==compress3(3,arr2,&nTargetLen,arr1,sizeof(“hello”)))  {   nTargetLen*=2;  }  while(Z_BUF_ERROR==uncompress3(3,arr3,&nTargetLen2,arr2,nTargetLen))  {   nTargetLen2*=2;  }

return 0; }

 

WSPSend

IT

WSPSend function

            This topic has not yet been rated – Rate this topic

WSPSend sends data on a connected socket.

Syntax

int WSPSend(
  _In_   SOCKET s,
  _In_   LPWSABUF lpBuffers,
  _In_   DWORD dwBufferCount,
  _Out_  LPDWORD lpNumberOfBytesSent,
  _In_   DWORD dwFlags,
  _In_   LPWSAOVERLAPPED lpOverlapped,
  _In_   LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine,
  _In_   LPWSATHREADID lpThreadId,
  _Out_  LPINT lpErrno
);

Parameters

s [in]
Descriptor that identifies a connected socket.

lpBuffers [in]
Pointer to an array of      WSABUF structures. This array must remain valid for the     duration of the send operation. Each WSABUF structure describes a buffer. The switch registered each     buffer in a previous call to the      WSPRegisterMemory function.

dwBufferCount [in]
Number of WSABUF structures at      lpBuffers.

lpNumberOfBytesSent [out]
Pointer to a variable that receives the number of bytes that      WSPSend sent.

dwFlags [in]
Must be zero.

lpOverlapped [in]
Pointer to a      WSAOVERLAPPED structure that provides a     communication medium between the initiation of an overlapped I/O operation and its subsequent     completion. Ignored for nonoverlapped sockets.

lpCompletionRoutine [in]
Pointer to the completion routine that the SAN service provider might initiate after the send     operation completes. Ignored for nonoverlapped sockets. The switch specifies NULL for a completion     routine. To see the prototype for a completion routine, see      WSPIoctl.

lpThreadId [in]
Pointer to a      WSATHREADID structure that the SAN service     provider might use in a subsequent call to the      WPUQueueApc function to arrange for the execution of the completion routine at      lpCompletionRoutine. A WSATHREADID structure identifies a thread. Because the switch specifies     NULL for a completion routine, the SAN service provider does not use      lpThreadId. For more information about      WPUQueueApc, see the Microsoft Windows SDK documentation.

lpErrno [out]
Pointer to a variable that receives the error code.

Return value

Returns zero if successful and the send operation completed immediately; otherwise, returns     SOCKET_ERROR and, at      lpErrno, one of the following error codes:

Return code Description
WSAENETDOWN
 Network subsystem failed.
WSAEFAULT
 The        lpBuffers parameter is not totally contained in a valid part of the user address space.
WSAENOBUFS
 SAN service provider reports a buffer deadlock.
WSAENOTCONN
 Socket is not connected.
WSAENOTSOCK
 Descriptor is not a socket.
WSAESHUTDOWN
 Socket has been shut down; it is not possible for the        WSPSend function to send data on a socket after the socket has been shut down.
WSAEINVAL
 The switch either did not create the socket with the overlapped flag or previously call the        WSPBind function to bind the socket.
WSAECONNABORTED
 The connection to the remote peer was terminated due to a time-out or other failure.
WSAECONNRESET
 The connection was reset by the remote peer.
WSA_IO_PENDING
 The SAN service provider successfully initiated an overlapped send operation and will indicate       completion at a later time.
WSA_OPERATION_ABORTED
 The overlapped operation was canceled, because the socket was closed.

 

Note that a SAN service provider does not support the following error codes for       WSPSend:

Return code Description
WSAEACCES
 Broadcast addresses are not supported.
WSAEINPROGRESS
 The Windows Sockets switch never issues cancel blocking calls to a SAN service provider.
WSAENETRESET
 Detecting a broken connection from the remote host resetting is not supported.
WSAEOPNOTSUPP
 The socket is the appropriate type.
WSAEWOULDBLOCK
 The Windows Sockets switch uses overlapped sockets.
WSAEMSGSIZE
 The current version of Windows Sockets Direct does not support SAN service providers handling       sockets that send datagrams.

 

Remarks

The Windows Sockets switch calls a SAN service provider’s     WSPSend function to transmit data on a connected socket. A SAN service provider receives     WSPSend requests from the switch, but never directly from an application.

Typically during connection setup time, the switch calls the SAN service provider’s     WSPRegisterMemory extension function to    preregister all memory for the buffer array that is the source of the outgoing data.

The switch specifies an overlapped structure and NULL for a completion routine if the switch calls the    SAN service provider’s     WSPSend function in an overlapped manner. The switch calls     WSPSend to post one or more buffers of data for transmission over the network. If the    data-transmission operation cannot complete immediately, the operation proceeds, but     WSPSend returns with the WSA_IO_PENDING error code. The switch later calls the SAN service    provider’s     WSPGetOverlappedResult function and    passes a pointer to the overlapped structure to retrieve the final completion status.

The buffer array that the switch supplies in a     WSPSend call is a pointer to an array of     WSABUF structures. The SAN service provider must    transmit data in buffers in the order in which those buffers appear in the buffer array. The buffer array    is transient. That is, if the     WSPSend call returns without completing the data-transmission operation, the SAN service provider    must capture the pointer to the array of WSABUF structures before returning from     WSPSend. This requirement enables the switch to build stack-based buffer arrays.

The switch does not pass send message requests to the SAN service provider that exceed the size that    the SAN service provider returns in     WSPGetSockOpt calls for the value of the    SO_MAX_MSG_SIZE socket option.

Note that the successful completion of a     WSPSend call does not indicate that the SAN service provider successfully finished delivering data    in the buffer array to the destination.

Overlapped Socket I/O

If the data transmission operation completes immediately, the SAN service provider returns from     WSPSend with a value of zero and specifies the number of bytes transmitted at     lpNumberOfBytesSent. If the SAN service provider successfully initiated the data transmission    operation and will indicate completion at a later time, the SAN service provider returns from     WSPSend with a value of SOCKET_ERROR and specifies the WSA_IO_PENDING error code at     lpErrno. Note that in this case, a value is not specified at     lpNumberOfBytesSent. After the data transmission operation completes, the switch calls the SAN    service provider’s     WSPGetOverlappedResult function and    passes a pointer to a variable to hold data transmission information. The SAN service provider specifies    the number of bytes transmitted in this pointer.

The overlapped structure at     lpOverlapped must be valid for the duration of the data transmission operation. If multiple data    transmission operations are outstanding simultaneously, each must reference a separate overlapped    structure.

As mentioned previously, the switch always specifies an event in an overlapped structure and NULL for    a completion routine if the switch calls the SAN service provider’s     WSPSend function in an overlapped manner. The SAN service provider should call the     WPUCompleteOverlappedRequest function in the context of an arbitrary thread to complete the data    transmission operation. If the low order bit of the     hEvent member in the WSAOVERLAPPED structure is set, the switch specifically requests to not be    notified upon completion of the data transmission operation. Therefore, the SAN service provider is not    required to call the     WPUCompleteOverlappedRequest function to complete the I/O request. In this case, the switch calls    the     WSPGetOverlappedResult function to poll for completion. For more information, see the     GetQueuedCompletionStatus function in the Microsoft Windows SDK documentation.

For more information about     WPUCompleteOverlappedRequest, see the Windows SDK documentation.

The SAN service provider can deliver completion notifications in any order; the SAN service provider    is not required to deliver notifications in the same order that overlapped operations are completed.    However, the SAN service provider transmits data from posted buffers in the same order in which the    switch supplies them.