02-05-2015
Quote:
Originally Posted by
Kovalevski
It is a very good point the MTU length, first of all thank you for this info because I didn't know , but when I tested the program, many messages arrived to the server
How large are your messages?
TCP is not received in dependably-sized chunks, it is a
stream. If they sent 30 bytes and you only read 2, that's okay, just read 28 more. Conversely, if they sent 5000 bytes and you got 1000, just keep reading, you'll get the rest eventually.
If the lengths are variable, you should encode them as part of the stream. Otherwise you won't know how much to expect and, as you've discovered, getting the "right" size from recv() is not dependable, mostly because there is no such thing.
I'm guessing you overloaded it until it was unable to cope. It started delivering data immediately instead of bundling multiple packets together politely.
Or, the server might even have been running out of memory. No kind of connection can cope with that. Each TCP connection takes a good chunk of it.
Last edited by Corona688; 02-05-2015 at 11:15 AM..
10 More Discussions You Might Find Interesting
1. IP Networking
I am trying to connect via DBACCESS and Informix server to a server on a different computer. When I execute the connect command from dbaccess I get the following message,
Exec format error cannot bind a name to the port.
As far as I know the port is not being used by another client.
How... (1 Reply)
Discussion started by: lopez
1 Replies
2. IP Networking
Hi Eveyone,
I have A small problems maybe some one can help me. I'm running a small network at home with internet access. Two PC's have Win XP and one has Win98se. I have them all hook up on a SMC router. ALL windows firewall are off and and harddrive sharing is on. I am using DCHP network... (3 Replies)
Discussion started by: Peterh
3 Replies
3. Solaris
I am running a Java Client on Solaris 9 which communicates with the Server using TCP/IP.
The client transmits a FIN packet to server. The server sends a ACK, FIN enters LAST_ACK state and then waits for ACK from client. The client did not respond back leaving the server in LAST_ACK itself. Also... (0 Replies)
Discussion started by: diarun
0 Replies
4. Programming
There is a server and a client,when client send a message to server,server can send a reply to client. The status of server and client is ESTABLISHED.Then I halt the client,I find the server status is CLOSE_WAIT and the client status is FIN_WAIT_2. Many minutes passed,I find the the server status... (1 Reply)
Discussion started by: konvalo
1 Replies
5. Programming
Greetings!
I am attempting to write a *basic* network client in C. I have manage to create a socket but I have doubts as far as using AF_INET vs AF_UNIX.
At the present time, my client runs with AF_INET. Is AF_UNIX faster across hosts using the same OS flavor (Red Hat)? What is the difference... (1 Reply)
Discussion started by: Alan Christen
1 Replies
6. Red Hat
how the data from disk is loaded into memory and then it transfered to tcp/ip packet.
how i can find how many pages are loaded into memory by that process
what is the rate of context switch for that process. (5 Replies)
Discussion started by: amar20
5 Replies
7. Shell Programming and Scripting
how the data from disk is loaded into memory and then it supplied to tcp/ip packet.
how i can trace the no of pages loaded in memory by that process and rate of context switch for that process. (1 Reply)
Discussion started by: amar20
1 Replies
8. Programming
Hello @ all,
I hope you can give me some advice :b:
I will be following code for a tcp server and doStuff () function, the
clients treated. From some point, I have several identical
clients (zombies, I think), the same records in the database
write. Has anyone an explanation? What can I... (1 Reply)
Discussion started by: yumos
1 Replies
9. IP Networking
Hello all.
This is my first post and thank you for your forum.
Here is my question.
I have a simple setup at home and I was capturing some data with wireshark.
Data between a workstation and the web server, requesting a page.
Simple enough.
Now when I open wireshark, I apply the TCP... (4 Replies)
Discussion started by: squaresphere
4 Replies
10. UNIX for Advanced & Expert Users
Hi all.
I have a really really weird problem that I've been working on for days.
The problem manifested as users cannot connect to our web servers via SSH when they're using our wireless network. Here's where it gets weird:
- Clients from anywhere other than the wireless subnet can... (4 Replies)
Discussion started by: pileofrogs
4 Replies
nfsiod(8) System Manager's Manual nfsiod(8)
NAME
nfsiod, biod - The local NFS compatible asynchronous I/O daemon
SYNOPSIS
nfsiod [ numthreads ]
DESCRIPTION
The nfsiod daemon runs on an NFS compatible client machine and spawns several IO threads to service asynchronous I/O requests to its
server. The I/O threads improve performance of both NFS reads and writes. Both try to enlist the aid of an idle I/O thread. If none is
available, the process itself issues the request to the server and waits for the reply.
The optimum number of I/O threads to run depends on many variables, such as how quickly the client will be writing, how many files will be
accessed simultaneously, and the behaviour of the NFS server. For use with a Tru64 UNIX server, 7 is a good number of I/O threads for most
systems.
When reading, if the client believes the process is reading a file sequentially, it requests an I/O thread to read a block ahead of what
the process is currently requesting. If the readahead completes before the process asks for that block, then the subsequent read system
call for that data completes immediately and does not have to wait for the NFS request to complete. Read ahead will be triggered again so
the read may find that next block available as well.
When writing a file, the client takes the process's data, passes the request to an I/O thread and immediately returns to the process. If
the process is writing data faster than the network or server can process, then eventually all the I/O threads become busy and the process
has to handle a NFS write itself. This means the process has to wait until the server finishes the write. For Tru64 UNIX servers, the NFS
block size is 8Kb and UFS tries to cluster I/O 64Kbs at a time. If the client is running with 7 I/O threads, 8 write requests can be in
progress at once. This allows the client and server to write data 64Kbs at a time and is the reason for recommending 7 I/O threads.
Unlike nfsd, each client thread can use either UDP or TCP. However, if TCP mounts are active, the nfsiod process will time out, close idle
TCP connections, and acknowledge any connections closed by the server.
The nfsiod process is also responsible for syncing the access time and modify times for special files and named pipes (fifos). Because I/O
to these files does not go through the NFS server, NFS clients have to directly update the access time and modify time attributes.
The client threads are implemented as kernel threads; they are part of Process ID 0, not the nfsiod process. The ps axml command displays
idle I/O threads under PID 0. Idle threads will be waiting on nfsiod_wait. Therefore, if 7 I/O threads are configured, only 1 nfsiod
process is displayed in the output from the ps command, although 7 client threads are available to handle NFS requests.
FILES
Specifies the command path Specifies the file for logging NFS activity.
RELATED INFORMATION
Commands: nfsd(8), nfsstat(8)
Daemons: async_daemon(2) delim off
nfsiod(8)