Read Packet by Packet


I have a TCP Server which is listening for incoming requets (Simple string format).

Trouble is if a client sends two packets and Servers executes a recv, both the packets come in same recv()

How can i read packet by packet.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

>>>> How can i read packet by packet.
If the packets have a fixed size, you could provide a buffer which takes exactly one packet but not more.

If the packets have variable size, the clients should add the length to their buffers, e, g. by using a struct like

   struct Packet
        unsigned int     siz : 32;
        unsigned char  buf[MAX_BUF_SIZ];

so that you easily could parse the received buffer for multiple packets.
>> How can i read packet by packet.

Not on recv level. You need to go on a lower level.

In fact, how do you know that the two sends were sent in different packets ?
carchitectAuthor Commented:
By running ethereal on server, i came to know that the packets received are two but when i make recv() call, i get the full data at one go.

Pls suggest

I would like to go for lower level if needed
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

>> By running ethereal on server, i came to know that the packets received are two but when i make recv() call, i get the full data at one go.

What I meant is : which data is put into which packets is decided on a lower level (not on application level). On the receiving end, the same is true : when the data received from packets is available to the application depends on the lower protocol stack levels.
Do not let your code rely on such things.

It shouldn't be a problem anyway ... Your code should simply receive data until it has read (at least) one message, then process the message (and leave the extra data in the buffer). After the message is processed, it checks the buffer - if there's another full message in the buffer, it processes that one - if not, it does another recv to receive more data. Etc.

>> I would like to go for lower level if needed

You don't need to :)
Note, if clients and server were on different platforms, you would need to check whether a struct like the above has the same alignment and size on eaxch of the platforms. To support platforms of different endian types the clients would need to assign the length in network order format by

     Packet p = { 0 };
     p.siz = htonl(strlen(message)+1);
     memcpy(p.buf, message, strlen(message)+1);
carchitectAuthor Commented:
Requirement is client can send various kinds of XML requests e.g. Login, Request etc
Every command has got different argument.
In addition, i need to implement one HeartBeat message between client and server (Necessity).

Now if i have sent one HB from Server to client, i am expecting one HB Reply but it can come along with other requests also like Login, Request etc.

I need to divide all before processing where as i go on packet level and sniff, all are coming as different packets only.

So i was wondering if there is any way to read packet by packet rather than by buffer.

Sequence of incoming packets can be anything. HB can come before Login and vice-versa.

>> So i was wondering if there is any way to read packet by packet rather than by buffer.

As I said : you shouldn't. You can simply process the buffer that contains the incoming data. Process the first message, then the second message, etc. When the buffer becomes empty, you recv some more.

That's the way all such applications work, and that's the way the TCP/IP protocol stack has been designed. The application level should not worry about packets - the lower level handle all of that, and provide a nice stream of data to the application.

One thought though : how come the client can send more requests, before the previous one has been processed ? If there's a login request, shouldn't the client wait until the login was approved by the server before sending more requests ?
Also, if the client sends multiple requests without waiting for the response, how will it know which responses were for which requests when they arrive ?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
carchitectAuthor Commented:
Thank you for showing such an interest.

1. Client can send more than one requests at a time as there is a requirement of Heart Beat Message from client to server and vice-versa at every defined time interval which is not related to other requests in progress.

2. Every request is coming with a Sequence Number from cleint and server responds back with that sequence number as one of the fields of the reply.
A heartbeat message should only be sent in periods where there are no requests, no ? When requests are being sent, there's no need for checking the connection, since that's already done by the actual requests being sent.

In any case, that doesn't change what I said earlier. If different requests can arrive before responses are sent, then the server simply processes those requests one by one, as they come in.

You need to make sure that it's easy to discern the boundaries between the different packets, but with XML, that shouldn't be a problem.
carchitectAuthor Commented:
Heart beat is coming from a 3rd party on which i have no control. I have to support it. Either server should send or client will send, irrespective of requests. (No other option to ignore it).

I will continue with the way you suggested. Reading buffer and diving it into various requests if it includes.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.