[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

socket

Posted on 2011-02-24
14
Medium Priority
?
510 Views
Last Modified: 2012-05-11
I have a client server application:

Client) Continues listen and waits on recv()
Server) has 2 threads
      Thread 1) Continously sends data
      Thread 2) Send data every 30 secs.

I have noticed many times,
1) Thread 2 in Server simply waits for ever during send()...
2) As soon as thread 1 sends some data, thread 2 just finishes.

What could be going wrong?


Can the server simply send() even though client is not waiting on recv()
0
Comment
Question by:learningunix
  • 6
  • 3
  • 2
  • +2
14 Comments
 
LVL 9

Expert Comment

by:AriMc
ID: 34975815
Sending the source codes of your applications could help.

0
 

Author Comment

by:learningunix
ID: 34975832
This what I have noticed:

Thread 1 and Thread 2 both calls socket send() using

mutex_lock()
  send();
mutex_unlock()

It looks like Thread 2 is holding the lock and waiting on send() forever (looks like client is not receiving at this time. What is the max data that can be send over the line?)
Because of this Thread 1 can't hold the lock.

0
 

Author Comment

by:learningunix
ID: 34975925
actually the other way, thread 1 continously sends data and after some time it just simply waits on send()
(probably client is not receiving). thread 1 is holding lock.

as a result thread 2 is not able to acquire lock.

The only reason I need thread 2 is to send a mesaage to client that i am still alive but thread 1 is already stuck in send()
0
NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

 

Author Comment

by:learningunix
ID: 34975947
the whole point of thread 2 is to make sure the connection is kept alive by sending message every 30 secs. in case thread 1 is taking some time.

However if the thread 1 itself can''t send anymore data (probably either client is not receiving or poll() is not allowing me to write ) how can thread 1 send any data.
0
 

Author Comment

by:learningunix
ID: 34976152
I need a way to keep the socket connection alive so that thread 1 does not throws exception
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34977011
If you don't want to block on send, then open the socket in non-blocking mode.
Also, you can use write() system call instead of send().

From the send() manpage, regarding blocking, this is what it says:
When  the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-blocking I/O mode.  In non-blocking mode it would return EAGAIN in this case.
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34977593
If you created a thread just to ensure that a connection is not dropped due to inactivity you should instead look at the OS facilities: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.

The very short summary of that howto is that the kernel can take care of this for you. And that you can set this up when creating the socket.
0
 
LVL 53

Accepted Solution

by:
Infinity08 earned 2000 total points
ID: 34977788
A few things that will probably help you figure out what's going wrong, and fix the problem :

(a) make sure that both threads use the same socket (id) - do that by using a shared variable

(b) make sure that both threads use a shared mutex (or other synchronization primitive) to control access to the shared socket

(c) make sure that both threads lock the mutex (if using a mutex) before each use of the socket, and release it as soon as they have finished using it. When using a loop, make sure to do the locking and releasing inside the loop (so as not to lock it for too long)

(d) always check all return values and/or error code for all function calls
0
 

Author Comment

by:learningunix
ID: 34979276
@infinity.

1. Yes both the the thread uses same socket desciptor
2. Before sending I use mutex to lock it and then release the lock
3. The issue is Thread 1 is somehow blocked after sending a large number of data?
4. Because of this my Thread 2 can't get lock on mutex and is not able to send keepalive packet
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34979414
>> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?

But the question is : where is it blocked and why ?

If it really is the send that is blocking, then ssnkumar's suggestion to use a non-blocking socket (and check all return codes) would resolve this for you.

If it's blocking on the lock, then there might be a deadlock, which you'll have to investigate.

If it's blocking somewhere else, then you need to find out where.

As I said : make sure to check and verify all return and error codes.
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34981639
> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?
Put a printf() before and after send() call and see if it is blocked on send().
If yes, then either you need to change the receiving socket, so that it does a recv() to get the data.

So, to continue to debug, you should find out, which call is blocking?
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34986256
And again: let the kernel handle this. Keepalive packets are put on the line when needed, but you will not have problems in your applications (server and client) with handling data that was sent as keepalive data.

looks like a typical case of reinventing the wheel..
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34986303
Sure, de2Zotjes, but it's still interesting to know what caused the issue, because it might be impacting other aspects of the code too.
0
 

Author Closing Comment

by:learningunix
ID: 35037867
locks were not released properly. I found out. Thx
0

Featured Post

Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
This article will show you step-by-step instructions to build your own NTP CentOS server.  The network diagram shows the best practice to setup the NTP server farm for redundancy.  This article also serves as your NTP server documentation.
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.
Suggested Courses

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question