Socket wrapper class

I've created this thin wrapper class for a socket project that I'm working on. Can someone review my class and give me some points on if I'm on right track?

#include 
#include 

const int MAX_RECV_LEN = 8096;
const int MAX_MSG_LEN= 1024;
const int PORT_NUM =  1200;

class Sokect
{

private:
    Sokect(){}
    void setSocketID(int socketFb){socketID = socketFb;}

    int portNum;
    int socketID;
    int blockFlag;
    int bindFlag; 

public:
    Sokect(int);

    ~Sokect(){
        closesocket(socketID);
    }

    void setReuseAddr(int);
    void getReuseAddr(int);
    void setKeepAlive(int);
    void getKeepAlive(int);
    void setLingerOnOff(bool);
    void getLingerOnOff(bool);
    void setLingerSecond(int);
    void getLingerSecond(int);
    void setSocketBlockFlag(int);
    void getSocketBlockFlag(int);

    //size of send & Receive Buffer
    void  setSendBufferSize(int);
    void  getSendBufferSize(int);
    void  setReceiveBuffferSize(int);
    void  getReceiveBuffferSize(int);

    int getSocketID() {return socketID;}
    int getPortNum() {return portNum;}

    friend ostream& operator<<(ostream&,mySocket&);

    //get systems error  
    void detectErrorOpenWinSocket(int*,string&);
    void detectErrorSetSocketOption(int*,string&);
    void detectErrorGetSocketOption(int*,string&);

};

There are at least a few things I think I'd do differently, at any rate.

const int MAX_RECV_LEN = 8096;
const int MAX_MSG_LEN= 1024;
const int PORT_NUM =  1200;

The ALL_CAPS convention was originally invented for macros. At least as far as I can tell, it was originally for function-like macros, to give a subtle warning that it might evaluate its argument more than once, so you needed to be careful about exactly how and where you applied it (especially to arguments that might have side effects).

It really doesn't make sense for a situation like this, so I'd prefer to avoid it. Regardless of the exact names you choose, it's probably better to avoid putting these variables in the global namespace any way. I'd consider wrapping the entire class in a namespace instead.

private:
    Sokect(){}

Assuming your compiler is recent enough to support it, I'd prefer to use =delete; to ensure that a ctor can't be accessed, rather than defining it as private.

[ ... ]

void setReuseAddr(int);
void getReuseAddr(int);
void setKeepAlive(int);
void getKeepAlive(int);
void setLingerOnOff(bool);
void getLingerOnOff(bool);
void setLingerSecond(int);
void getLingerSecond(int);
void setSocketBlockFlag(int);
void getSocketBlockFlag(int);

I think rather than embedding these directly into the socket itself, I'd create a separate socket_options (or something similar) struct to hold them. This would allow (for example) storing an entire set of options together, so you can set all the options for a particular socket at once.

//size of send & Receive Buffer
void  setSendBufferSize(int);
void  getSendBufferSize(int);
void  setReceiveBuffferSize(int);
void  getReceiveBuffferSize(int);

Likewise, I'd probably create a small class just to handle the buffering. Then the socket class could just contain two buffer instances, one for receiving and one for sending.

//get systems error  
void detectErrorOpenWinSocket(int*,string&);
void detectErrorSetSocketOption(int*,string&);
void detectErrorGetSocketOption(int*,string&);

These seem to me like they merit at least a little more explanation of what they're actually supposed to be/do.

StackExchange Code Review Q#43369, answer score: 8