Struct I want to send:
struct Client
{
SOCKET socket = 0;
float m_fX = 0;
float m_fY = 0;
float m_fRot = 0;
bool m_bIsAlive = false;
Powerups m_ePowerup = Powerups::lazer;
};
Client Sending Struct to Server:
char* buffer = new char[sizeof(Client)];
memcpy(buffer, &dataToServer, sizeof(Client));
send(sock, (char*)dataToServer, sizeof(Client), NULL);
Server Receiving Struct from Client:
char* buffer = new char[sizeof(Client)];
recv((SOCKET)socketData, buffer, sizeof(Client), NULL);
memcpy(m_pClients[i], (void*)buffer, sizeof(Client));
std::cout << "\tSocket: " << (int)(SOCKET)socketData << "\t" << m_pClients[i]->m_bIsAlive << std::endl;
Why does this print out as though m_pClients[i]->m_bIsAlive = 205?
char* buffer = new char[sizeof(Client)];
memcpy(buffer, &dataToServer, sizeof(Client));
send(sock, (char*)dataToServer, sizeof(Client), NULL);
Looks to me like you meant for the second parameter to send() to be buffer, here. Additionally, if dataToServer is a pointer to a Client structure, the second parameter to memcpy() should not be a pointer to this pointer.
Additionally, your code fails to check the return value from both send() and recv() also. Just because you asked to send sizeof(Client) bytes, you have absolutely no guarantee whatsoever that this request will succeed, or that many bytes will be written.
The same thing goes for recv() too. You must always check the return value from every system call, be prepared to handle errors and every possible return value, unless external circumstances (there are few cases like that) guarantee that the system call will never fail.
Related
I want to send() body and header which has body size from the Side A.
On the Side B, in the first recv() header to determine the size of payload. The second, recv() body.
I tried to use recv() twice but could not through the second recv() function.
Side A
struct CommandHeader_t {
int BodySizeByte;
};
void Send()
{
const int BODY_SIZE_BYTE = 10;
CommandHeader_t* header_ptr = (CommandHeader_t*) malloc(sizeof(CommandHeader_t) + BODY_SIZE_BYTE);
header_ptr->BodySizeByte = BODY_SIZE_BYTE;
char* body_ptr = (char*) (header_ptr + sizeof(CommandHeader_t));
snprintf(body_ptr, BODY_SIZE_BYTE, "Hello World");
int sock = socket(AF_LOCAL, SOCK_DGRAM, 0);
struct sockaddr_un addr = {0};
addr.sun_family = AF_LOCAL;
strcpy(addr.sun_path, SENDING_SOCKET);
sendto(sock, header_ptr, sizeof(CommandHeader_t) + BODY_SIZE_BYTE, 0, (const struct sockaddr*)&addr, sizeof(addr));
close(sock);
}
Side B
void Reveice()
{
// something
CommandHeader_t header;
char* body_ptr;
recv(sockfd, &header, sizeof(CommandHeader_t), 0);
body_ptr = (char*) malloc(header.BodySizeByte);
recv(sockfd, body_ptr, header.BodySizeByte, 0); // CANNOT recv anything
}
There are some mistakes in your code:
On the sending side, you are not doing pointer arithmetic correctly when assigning the body_ptr pointer. As header_ptr is declared as CommandHeader_t*, doing (header_ptr + sizeof(CommandHeader_t)) will calculate a memory address that is sizeof(CommandHeader_t) number of CommandHeader_t elements past the address that header_ptr is pointing at. That is not what you want. You need to instead calculate an address that is sizeof(CommandHeader_t) number of chars past the header_ptr address.
So, you need to change this:
char* body_ptr = (char*) (header_ptr + sizeof(CommandHeader_t));
To this instead:
char* body_ptr = ((char*) header_ptr) + sizeof(CommandHeader_t);
A simpler way to handle this is to add a char[1] member to CommandHeader_t, and then subtract 1 when malloc()'ing it, eg:
#pragma pack(push, 1) // or equivalent
struct CommandHeader_t {
int BodySizeByte;
char data[1];
};
#pragma pack(pop) // or equivalent
CommandHeader_t* header_ptr = (CommandHeader_t*) malloc(offsetof(CommandHeader_t, data) + BODY_SIZE_BYTE);
header_ptr->BodySizeByte = BODY_SIZE_BYTE;
char* body_ptr = header_ptr->data;
snprintf(body_ptr, BODY_SIZE_BYTE, "Hello World");
Also, since you are using SOCK_DGRAM on the sending side, the sendto() is message-oriented, sending the entire data in 1 message. But your receiving code is written as if it were using a stream-oriented socket instead. Don't mismatch socket types like that. If you want to call recv() multiple times, use a stream-oriented socket on both sides. Otherwise, use a message-oriented socket on both sides, and then have the receiver allocate a buffer large enough to receive an entire message in 1 recvfrom() (you can use ioctl(FIONREAD) to determine the size of the next pending message), and then parse the contents of that message as needed.
Also, your receiver is leaking the body_ptr buffer it allocated with malloc().
I'm working on a webserver framework in C++ mostly for my own understanding, but I want to optimize it as well.
My question is is it faster to write multiple char arrays to the TCP connection for every html response or to spend the time to concatenate up front and only write to the TCP connection once. I was thinking about benchmarking it, but I am not quite sure how to go about it.
This is my first post on stackoverflow, although I have benefitted from the website very often!
Thanks!
Here is what I am talking about for sending many char arrays individually. The alternate would be concatenate all of these char arrays into one char array then sending that.
int main() {
sockaddr_in address;
int server_handle;
int addrlen = sizeof(address);
if ((server_handle = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
perror("cannot create socket");
exit(0);
}
memset((char *) &address, 0, sizeof(address));
address.sin_family = AF_INET;
address.sin_addr.s_addr = htonl(INADDR_ANY);
address.sin_port = htons(PORT);
if (bind(server_handle, (sockaddr *) &address, (socklen_t) addrlen) < 0)
{
perror("bind failed");
exit(0);
}
if (listen(server_handle, 3) < 0)
{
perror("In listen");
exit(EXIT_FAILURE);
}
while(1) {
std::cout << "\n+++++++ Waiting for new connection ++++++++\n\n";
int client_handle;
if ((client_handle = accept(server_handle, (struct sockaddr *)&address, (socklen_t *) &addrlen))<0)
{
perror("In accept");
exit(EXIT_FAILURE);
}
// read and respond to client request
char buffer[30000] = {0};
int bytesRead = read(client_handle, buffer, 30000);
char * httptype = "HTTP/1.1 ";
char * status = "200 \n";
char * contenttype = "Content-Type: text/html \n";
char * contentlength = "Content-Length: 21\n\n";
char * body = "<h1>hello world!</h1>";
write(client_handle, httptype, 9);
write(client_handle, status, 5);
write(client_handle, contenttype, 26);
write(client_handle, contentlength, 20);
write(client_handle, body, 21);
std::cout << "------------------Response sent-------------------\n";
close(client_handle);
}
}
If you want to send multiple buffers with a single write call you can use vectored IO (aka scatter/gather IO) as the manual suggests:
char *str0 = "hello ";
char *str1 = "world\n";
struct iovec iov[2];
ssize_t nwritten;
iov[0].iov_base = str0;
iov[0].iov_len = strlen(str0);
iov[1].iov_base = str1;
iov[1].iov_len = strlen(str1);
nwritten = writev(STDOUT_FILENO, iov, 2);
In fact it writing to a socket is not really different from writing to a file descriptor. And the fwrite function was introduced to the C library for a reason: write (be it to a TCP connection or to a file descriptor) involve a system call on common OS and a context change user/kernel. That context change has some overhead, mainly if you write small chunks of data.
On the other hand, if you write larger chunks of data in sizes that are close to the physical size for the underlying system call (disk buffer for a file descriptor, or max packet size for a network socket), the fwrite call or in your example the code concatenating char arrays will not really lower the system overhead and will just add some user code processing.
TL/DR: this depends on the average size of what you write. The smaller it is, the higher benefit of concatenating the date in larger chunks before writing. And remember: this is a low level optimization that should only be considered if you have identified a performance bottleneck or if the code could be used in a broadly distributed library.
I am trying to check if a client has send some new data. This actually tells me that i always have new data:
bool ClientHandle::hasData()
{
fd_set temp;
FD_ZERO(&temp);
FD_SET(m_sock, &temp);
//setup the timeout to 1000ms
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = 1000;
//temp.fd_count possible?
if (select(m_sock+1, &temp, nullptr, nullptr, &tv) == -1)
{
return false;
}
if (FD_ISSET(m_sock, &temp))
return true;
return false;
}
I am connecting with a java client and send a "connection" message which i read inside of the ctor:
ClientHandle::ClientHandle(SOCKET s) : m_sock(s)
{
while (!hasData())
{
}
char buffer[5];
recv(m_sock, buffer, 4, NULL);
auto i = atoi(buffer);
LOG_INFO << "Byte to receive: " << i;
auto dataBuffer = new char[i + 1]{'\0'};
recv(m_sock, dataBuffer, i, NULL);
LOG_INFO << dataBuffer;
//clean up
delete[] dataBuffer;
}
This seems to work right. After that i keep checking if there is new data which always is true even if the java client does not send any new data.
Here is the java client. Don't judge me it's just for checking the connections. It wont stay like this to send the size information as char[].
public static void main(String[] args) throws UnknownHostException,
IOException {
Socket soc = null;
soc = new Socket("localhost", 6060);
PrintWriter out = new PrintWriter(soc.getOutputStream(), true);
BufferedReader in = new BufferedReader(new InputStreamReader(
soc.getInputStream()));
if (soc != null)
System.out.println("Connected");
out.write("10\0");
out.flush();
out.write("newCon\0");
out.flush();
out.close();
in.close();
soc.close();
}
So what is wrong with the hasData FD_ISSET method?
So what is wrong with the hasData FD_ISSET method?
Actually no. There is a problem with your use of recv().
recv() will return 0 if the client is disconnected and will return this until you close the socket (server-side). You can find this information in the manual.
Even if recv() returns 0, it will "trigger" select().
Knowing that, it's easy to find out the problem: you never check the return value of recv() and so you're unable to say if the client is still connected or not. However, you still add it with FD_SET!
#include <sys/types.h> // for ssize_t
#include <stdio.h> // for perror()
ClientHandle::ClientHandle(SOCKET s) : m_sock(s)
{
while (!hasData())
{
}
char buffer[5];
ssize_t ret = recv(m_sock, buffer, 4, NULL);
if (ret == -1) // error
{
perror("recv");
return ;
}
else if (ret == 0) // m_sock disconnects
{
close(m_sock);
// DO NOT FD_SET m_sock since the socket is now closed
}
else
{
auto i = atoi(buffer);
LOG_INFO << "Byte to receive: " << i;
auto dataBuffer = new char[i + 1]{'\0'};
recv(m_sock, dataBuffer, i, NULL);
LOG_INFO << dataBuffer;
//clean up
delete[] dataBuffer;
}
}
From Steven's book UNIX Networking Programming:
A socket is ready for reading if any of the following four conditions is true:
The number of bytes of data in the socket receive buffer is greater than or equal to the current size of the low-water mark for the socket receive buffer. A read operation on the socket will not block and will return a value greater than 0 (i.e., the data that is ready to be read). We can set this low-water mark using the SO_RCVLOWAT socket option. It defaults to 1 for TCP and UDP sockets.
The read half of the connection is closed (i.e., a TCP connection that has received a FIN). A read operation on the socket will not block and will return 0 (i.e., EOF).
The socket is a listening socket and the number of completed connections is nonzero. An accept on the listening socket will normally not block, although we will describe a timing condition in Section 16.6 under which the accept can block.
A socket error is pending. A read operation on the socket will not block and will return an error (–1) with errno set to the specific error condition. These pending errors can also be fetched and cleared by calling getsockopt and specifying the SO_ERROR socket option.
ISSET is going to return true in all the cases above. After your Java client closes the connection, the socket will be ready for reading in the server.
In ClientHandle::ClientHandle you are not checking the return value of recv and if any data is returned.
Is it blocking in the second call to recv?
You don't check the return value of recv and you don't handle receiving fewer bytes than you asked for. So what do you expect to happen when the connection is closed?
I seem to have an issue with increasing latency on my packet transmission with my TCP server. Now, this server has to be TCP, since UDP is blocked by firewalls (this is a client-server-client type of communication). I'm also aware that the sending of a struct with floating point integers as I am is extremely non-portable, however, this system will operate Windows client to Windows server to Windows client for the foreseeable future.
The issue is this: the client begins receiving the data properly from the other client, however, there is a delay which gets exponentially worse (where, by about 3 minutes in, the packets are nearly 30 seconds behind - but correct, when they DO arrive). I researched it and found an answer on a Microsoft page explaining it is due to full send buffers, however, their syntax for the setsockopt doesn't match the documented examples, so perhaps I'm wrong.
Anyway, any advice would be appreciated:
The relevant part of the server:
(When accept() is called:)
int buff_size = 2048000;
int nodel = 1;
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (char*)&buff_size, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (char*)&buff_size, sizeof(int));
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char*)&nodel, sizeof(nodel));
The message redirect loop:
if (gp->curr_pilot < sz && gp->users[gp->curr_pilot].pilot == TRUE) {
char* pbuf = new char[1024];
int recvd = recv(gp->users[gp->curr_pilot].sockfd_data, pbuf, 1024, NULL);
if (recvd > 0) {
for (int i = 0; i < sz; i++) {
if (i != gp->curr_pilot && gp->users[i].unioned == TRUE)
send(gp->users[i].sockfd_data, pbuf, recvd, NULL);
}
}
delete[] pbuf;
}
The client (master is set when it's sending, and it does get set properly by my code):
(data is my struct of doubles that gets written by the client, cdata is a copy of it that gets written into the client).
while (kill_dataproc == FALSE) {
if (master == TRUE) {
char* buff = new char[1024];
int packet_signer = 1192;
memcpy_s(buff, intsz, &packet_signer, intsz);
memcpy_s((void*)(buff + intsz), sz, data, sz);
send(server_sock, buff, buffsize, NULL);
delete[] buff;
}
else {
char* buffer = new char[1024];
int recvd = recv(server_sock, buffer, 1024, MSG_PEEK);
if (recvd > 0) {
int newpacketsigner = 0;
memcpy_s(&newpacketsigner, intsz, buffer, intsz);
if (newpacketsigner == 1192) {
if (recvd >= buffsize) {
char* nbuf = new char[buffsize];
int recvd2 = recv(server_sock, nbuf, buffsize, NULL);
int err = WSAGetLastError();
memcpy_s(&newpacketsigner, intsz, nbuf, intsz);
memcpy_s(cdata, sz, (void*)(nbuf + intsz), sz);
//do things w/ the struct
delete[] nbuf;
}
}
else
recv(server_sock, buffer, 1024, NULL);
}
delete[] buffer;
}
Sleep(10);
}
As well, identical calls to setsockopt and are called for the client's sockets, and all of the sockets, server and client, are nonblocking.
You're assuming that your reads are filling the buffer. They are only obliged to transfer at least one byte. You you need to loop.
So, you have unread data backing up and stalling the sender.
NB Those receive buffers are greater than 64k and so may be inoperative unless they are set before the socket is connected. In the case of the server you need to set the receive buffer size on the listening socket. Accepted sockets will inherit it. If you don't to it his way, window scaling won't be in effect so a window > 64k cannot be advertised (unless the platform has window scaling on by default).
I'm currently trying to implement SOCKS 4/5 functionality in my C++ program (i.e. requests to arbitrary protocols and hosts can be redirected through a given SOCKS proxy if desired). I'm developing purely for Windows so using Winsock 2.
My problem is slightly less abstract than simply "how does this work" though. I've read the RFC for SOCKS 4 (I decided to implement SOCKS 4 first since it has less bytes in its requests to contend with) but I'm struggling to create the C string I need to send().
At present, I have a struct defined called Socks4Msg which looks like this:
struct Socks4Msg {
const static uint8_t version = 0x04; //SOCKS version 4 (obviously)
const static uint8_t command = 0x01; //1 is TCP CONNECT command
const static uint8_t nullbyte = 0x00; //null byte sent at message end
uint16_t port; //16 bit/2 byte port (network order)
uint32_t ip; //32 bit/4 byte IP address (network order)
Socks4Msg(uint16_t p, uint32_t i) : port(p), ip(i) { }
};
The function which creates the actual socket and does the work is here (where p and h hold the port and host to test through the proxy -- p is a string to maintain compatibility with HttpProxy which I've already implemented). port and addr are part of the class and are an int and string respectively; they're the details of the proxy server.
int Socks4Proxy::test(std::string p, std::string h) const {
uint16_t network_port = htons(str_to_numt<uint16_t>(p));
uint32_t network_ip = hostname_to_ip(h);
Socks4Msg msg_struct(network_port,network_ip);
SOCKET s = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
int last_error;
if(s == INVALID_SOCKET) {
last_error = WSAGetLastError();
std::cerr << "Failed to initialise socket! Error code: " << last_error << std::endl;
return 2;
}
sockaddr_in st_addr;
st_addr.sin_family = AF_INET;
st_addr.sin_port = htons(port);
ipaddr_t ip = inet_addr(addr.c_str());
st_addr.sin_addr.S_un.S_addr = ip;
if(connect(s,(sockaddr*)&st_addr,sizeof(st_addr))!=0) {
last_error = WSAGetLastError();
std::cerr << "Socket failed to connect. Error code: " << last_error << std::endl;
return 2;
}
uint8_t message[13];
uint8_t* message_ptr;
memset(message, 0, 13);
message_ptr = message;
*message_ptr = msg_struct.version;
message_ptr++;
*message_ptr = msg_struct.command;
message_ptr++;
*message_ptr = msg_struct.port;
message_ptr += 2;
*message_ptr = msg_struct.ip;
message_ptr += 4;
*message_ptr = 'b'; message_ptr++; *message_ptr = 'o'; message_ptr++; *message_ptr = 'b'; message_ptr++;
*message_ptr = msg_struct.nullbyte;
message_ptr++;
*message_ptr = 0x00;
char smessage[13];
memcpy(smessage, message, 13);
int return_val;
while(return_val = send(s, smessage, strlen(smessage), 0)) {
if(return_val == SOCKET_ERROR) {
last_error = WSAGetLastError();
std::cerr << "Writing data failed. Error code: " << last_error << std::endl;
return 2;
}
//implement return_val < strlen(message) here
else break;
}
//remainder of function
I have tested and verified that the members of msg_struct contain the correct data (and in the correct byte order) before the C string manipulation starts.
I've tried doing it using memcpy() (e.g. memcpy(message_ptr, &msg_struct.port, 2)) in place of the assignments but I just can't understand why Wireshack always quotes the byte length of the sent data as 2 (i.e. version and command) but nothing else. (I know my knowledge of C strings - and therefore the code at that point - is a bit rough but I can't explain why it doesn't work)
Any advice would be greatly appreciated!
First of all message_ptr is uint8_t* and *message_ptr = msg_struct.ip; is wrong. You should cast message_ptr to uint_32t* and then assign data, like * ((uint32_t*)message_ptr) = msg_struct.ip; otherwise msg_struct.ip will be converted to uint8_t and then assigned. Same problems with other fields.
Check this and let me know if it is woring again :)
BTW. I think Wireshark network traffic analyzer could help you a lot in searching such kind of problems.
UPDATE
Probably a better idea is to create a structure which represents the message you want to send and cast message_ptr to the pointer on this structure. But do not forget to tell your compiler not to add any paddings.
UPDATE 2
Network and host byte order.
Do not forget that you should change bytes order using hton, ntoh, htonl or ntohl functions.