I am relatively new to JMeter however I have been doing Performance testing for almost a decade.
I am working with a proprietary TCP protocol that sends a keep alive periodically - through the existing TCP connection.
I am struggling to understand how I can fork the JMeter 'thread group' to handle a TCP Keep alive received over the same TCP session.
Any ideas?
Thank you brainstrust!
edit: I'm using the TCPsampler and have read the help page. I'll try to provide some more detail shortly about what's happening and how the protocol is written.
edit2: Unfortunately because it's a propriety protocol I cannot reveal the exact nature of the protocol itself but it's largely irrelevant to the problem I'm facing.
Basically, I use the 1st TCP sampler to 'start/authenticate' the session with the server. This is configured the following options:
1. TCPClient classname: LengthPrefixedBinaryTCPClientImpl (my protocol is implemented this standard way)
2. Re-use connection ON.
3. Close connection OFF.
4. Set NoDelay OFF.
5. SO_Linger: nothing
6. Text to send: my hex code for the protocol (this is correct)
I get the response from the first TCP request and then I want to start interacting, however in the session, the server sends a keep alive mid-stream, so occassionally when I send a request, I get an unexpected keep alive response instead (it's an open stream of data).
This is what I would like to solve.
I attempted to use a recursive test fragment, so that on KeepAlive response, it would send the request again however one cannot recurse the test fragments (it throws a Java error on Run attempt).
I hope this gives more context! Thank you for your patience (I'm a newbie SO user!)
Please check the below options if it helps with you sceario:-
If "Re-use connection" is selected, connections are shared between
Samplers in the same thread, provided that the exact same host name
string and port are used. Different hosts/port combinations will use
different connections, as will different threads. If both of "Re-use
connection" and "Close connection" are selected, the socket will be
closed after running the sampler. On the next sampler, another socket
will be created. You may want to close a socket at the end of each
thread loop.
If an error is detected - or "Re-use connection" is not selected - the
socket is closed. Another socket will be reopened on the next sample.
The following properties can be used to control its operation:
tcp.status.prefix text that precedes a status numbertcp.status.suffix
text that follows a status numbertcp.status.properties name of
property file to convert status codes to messagestcp.handler Name of
TCP Handler class (default TCPClientImpl) - only used if not specified
on the GUI
For more details:-https://jmeter.apache.org/usermanual/component_reference.html#TCP_Sampler
Related
All required changes have been done to respective files like:
stalecheck=true,
keepalive is checked from HTTP request defaults,
retrycount=1,
hc.parameters file changes,
Socket timeout is 240000
Still we see "java.net.SocketException: Connection reset" in response data however I see the valid requests been passed to Server.
The issue wasnt till we reach 3000 users, worked smoothly till 3000 users.
Connection Reset has a lot of meaning, possible reasons are:
One of the server components is not able to handle load so it closes connections on its side
On JMeter side, check that you running in NON GUI mode and that neither JMeter JVM nor injector machine are overloaded which could explain this. See:
https://jmeter.apache.org/usermanual/get-started.html#non_gui
I am working on an FTP client for kicks and I am trying to understand the workflow of data connections.
As I understand, the initial (command) connection is permanent until you quit. However, I am unsure of the data connection - is it re-initiated per-command? So you call PORT ... or PASV, get a second connection, do a LIST, get the results, connection closes, start over?
Also, do you need to call PASV (or PORT ...) again after each connection closes? It seems that when I try to test some things out using a passive connection, I cannot re-connect to the same port after the first command has returned the results and closed the data connection. I can keep calling PASV -> Data Connect -> Run Command -> Get Results -> Data Connection closed -> PASV, but it seems like it's not how it's meant to run?
Also, if someone has a good material on FTP that is more terse than the RFC I really appreciate it.
You have to open a new connection every time. It's only the closing of the connection, how you (or the server) can tell that the transfer completed (at least in the common "stream mode").
You cannot even reuse the local/remote port number combination, as when a TCP connection is closed, it enters TIME_WAIT mode and the port number combination cannot be used for some time. So for two immediately consecutive transfers you have to use a different port number combination anyway.
Refer to RFC 959, section 3.3. Data management:
Reuse of the Data Connection: When using the stream mode of data
transfer the end of the file must be indicated by closing the
connection. This causes a problem if multiple files are to be
transfered in the session, due to need for TCP to hold the
connection record for a time out period to guarantee the reliable
communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port. The second is to use another
transfer mode.
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer modes
(Block, Compressed) do not close the connection to indicate the
end of file. They have enough FTP encoding that the data
connection can be parsed to determine the end of the file.
Thus using these modes one can leave the data connection open
for multiple file transfers.
See also:
Why does FTP passive mode require a port range as opposed to only one port?
How many data channel ports do I need for an FTPS server running behind NAT?
A few weeks ago I wrote a small program which created a socket to an apache webserver and made a request.
Back then I did not know that this web server had a KeepAliveTimeout of 5 seconds.
After my first request I waited 1 minute. After this I wanted to reuse my first socket for another webserver request, but got an error.
From Beej's Guide to Network Programming I learned that if recv returns 0, then the other side has closed its connection:
Wait! recv() can return 0. This can mean only one thing: the remote side has closed
the connection on you! A return value of 0 is recv()'s way of letting you know this
has occurred.
My questions are now:
What does Apache send when the KeepAliveTimeout is over - a FIN or a RST packet?
I know that using a TCP connection for 2 unrelated HTTP requests like in this scenario might
not be the best thing. But in order to understand TCP more the next question is:
After my first successful http request, and before sending the next HTTP request over the same socket, would there be somehow a possibility to get informed about this keepalivetimeout TCPsocket termination of the server other than receiving 0 from the next recv() call?
It will send a FIN. If you write a request to the server after that, send() will return -1 with errno/WSAGetLastError() = ECONNRESET.
would there be somehow a possibility to get informed about this keepalivetimeout tcp socket termination of the server
Yes, by reading the proper response header parameter, namely Keep-Alive: timeout=delta-seconds:
'timeout' Parameter
A host sets the value of the timeout parameter to the time that the host will allows an idle connection to remain open before it is closed. A connection is idle if no data is sent or received by a host.
The value of the timeout parameter is a single integer in seconds.
A host MAY keep an idle connection open for longer than the time that it indicates, but it SHOULD attempt to retain a connection for at least as long as indicated.
As you can see, it's up to the host to decide. Given it only SHOULD try to keep the connection open as long as promised, but it isn't required that it does in order to conform to the spec, so the server might decide to close and reuse the connection to serve another pending client.
I need to close UDP socket which has unsent data immediately.
There is SO_LINGER parameter for TCP sockets but I didn't find out anything for UDP.
It's on Windows.
Thanks in advance.
Update 0:
I give background of this question. I have application 1st thread opens/binds/closes socket, 2nd thread sends datagrams to it.
In some cases after closing the socket (errorcode = 0) bind function returns errorcode 10048 "Address already in use". I found out after close() execution port is still used (via netstat command). Maybe I ask incorrect question and the reason of such behavior is something else?
For all application purposes once your send() returns, the packet is "sent". There's no send-buffer like in TCP, and you have no control over the NIC packet queue. Normal close() is all you need.
Edit 0:
#EJP, here's a quote from UNP for you (Section 2.11 "UDP Output"):
This time, we show the socket send buffer as a dashed box bacause it
doesn't really exist. A UDP socket has a send buffer size (which we
can change with the SO_SNDBUF socket option, Section 7.5), but this
is simply an upper limit on the maximum-sized UDP datagram that can
be written to the socket. If an application writes a datagram larget
than the socket send buffer size, EMSGSIZE is returned. Since UDP is
unreliable, it does not need tp keep a copy of the application's data
and does not need an actual send buffer. (The application data is
normally copied into a kernel buffer of some form as it passes down
the protocol stack, but this copy is discarded by the datalink layer
after the data is transmitted.)
This is what I meant in my answer - you have no control over the send buffer - , so "for all application purposes" it does not exist.
I was having this problem with a windows UDP socket as well. After hours of trying everything I finally found my problem was that I was calling socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) on the main thread to create the socket, calling bind(...) and recvfrom() on a worker thread, then after closing the worker thread I called closesocket(...) on the main thread. None of the functions returned an error but tor some reason, doing this leaves the UDP address/port combination in use (so a future call to bind() triggers error 10048 WSAEADDRINUSE and netstat -abot -p UDP also shows the port still in use until the whole application is closed). The solution was to move socket(...) and closesocket(...) calls into the worker thread.
Other than weird issues like the case above, there is normally no way that a UDP server socket can be left open after calling closesocket() on it. Microsoft explains that there is no connection maintained with a UDP socket and no need to call shutdown() or any other function. Usually the reason a TCP socket is left open after calling closesocket() is that it wasn't disconnected gracefully and it's waiting for about 4 minutes in TCP_WAIT state for possible additional data to come in before it actually closes. In the case above, netstat showed the UDP socket never closed until the application was closed even if I waited 30+ minutes.
If you're using a wrapper around winsock like the .NET framework, I've also read some features like setting up async callbacks can leave a UDP socket bound open if you don't clean up the callbacks correctly, but I don't think there are any such features in the win32 winsock API that can cause that.
Just close it. There's nothing in UDP that says that pending data will be sent, unlike TCP.
In order to receive datagrams through an UDP connection I have created an object of type UDPClient.
receivedNotificationSock = new UdpClient();
However once done and on using the receive method:
receivedHostNameBuffer=receivedNotificationSock.Receive(ref receivedNotificationIP);
I am getting an exception saying that I must call the bind method.
But there is no bind method in the UDPClient class.
Could You guys please provide me with the code if possible as to what should be done to overcome this exception.
You need I think to know some more about sockets.
All sockets possess a port number. First, you create a socket - which is almost useless on its own. It just floats there. But then you bind it - you assign it a port number. Now it's useful - now you can send and receive data on it.
Remember, all UDP communications are defined by the quad data set of the IP and port of the source and the IP and port of the destination. A freshly created socket doesn't have an IP address or port; binding gives it an IP address and port.
Unfortunately, I'm not a C# programmer, so I can't properly answer your question. But at least you know why it's important.
Pass the port number into the constructor of your UDP client.
receivedNotificationSock = new UdpClient(21000);
You may need to change firewall settings to allow the bind, though a popup window normally opens when you first run this on your dev machine.
For Socket proramming you need to know the sequence of syscalls you need to do on client side and on the server side.
If you are writting a client :
you open a socket with a socket call.
you then connect to the server port with a connect call
once connect is successful
then you send the request to the server using either a send or sendto or a write
which results in reception of data that you can read using a receive or read
On Server Side
you create a socket
bind it to a port
start listening on the socket for incoming connections from various clients using a listen.
There is a non blocking way of listening for connections as well with a select syscall.
Once the you establish a connection you can essentially read the request and start processing it.
Here's an example in C# that may be useful to you.
http://www.developerfusion.com/article/3918/socket-programming-in-c-part-1/